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ABSTRACT 



An attachment integrated claims (AIC) system includes an 
e-mail form (with specific fields that must be filled out) that 
adjusts itself, in both information required and formatting, to 
meet the demands of the receiving party. It is particularly 
advantageous for Electronic Data Interchange (EDI) situa- 
tions where a user must send similar (but not necessarily 
identical) messages to several organizations. This is particu- 
larly important where, once an e-mail is received by those 
organizations, the information in the message must be 
digitally integrated into differing legacy information sys- 
tems. In other words, the AIC system permits transmission 
of a dynamic claim form and integrated attachment to an 
insurance carrier via a non-clearinghouse communications 
channel. An AIC system including several computers con- 
nected via a communications channel, an electronic file, and 
an operating method therefor are also described. 
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ATTACHMENT INTEGRATED CLAIMS 
SYSTEM AND OPERATING METHOD 
THEREFOR 

This application is a con of Ser. No. 09/232,805 Jan. 19, 5 
1999 U.S. Pat. No. 6,076,066 which is a con of Ser. No. 
08/824,010 Mar. 25, 1997 U.S. Pat. No. 6,003,007 and 
claims benefit of Ser. No. 60/014,427 Mar. 28, 1996. 

BACKGROUND OF THE INVENTION 10 

The present invention relates generally to an attachment 
integrated claims (AIQ system for preparing and processing 
forms with integrated attachments. More specifically, the 
present invention relates to a Customizable Claim Form, i.e., 
a Dynamic Claim Form (DCF) suitable for use with an AIC 15 
system. A method of operating a totally digital AIC system 
while employing a DCF is also disclosed. 

High administrative costs for filing and processing health 
insurance claims have been the bane of the health insurance 
industry from its inception. Over the years, many attempts 20 
have been made to develop a faster and more cost effective 
claims processing system. Three stages in this development 
effort are described in the following correspondingly num- 
bered paragraphs.' 

(1) The original system involved hard copy paper claims 25 
only, with transmission and all processing done manually. 
Originally, an insurance claim was filed by the patient or the 
health care provider filling out a paper form. The completed 
paper form was then mailed to the insurance company. At 
the insurance company, the paper claim form went through 

a series of administrative steps, all the time remaining as a 
hard copy paper object. When a decision was made, the 
decision was written up and archived with the claim form; 
a hard copy was also sent to the patient and/or provider 
along with the payment. 

(2) The first significant advancement resulted from the 
introduction of the mainframe computer. This allowed for 
electronic processing within a given insurance company, i.e., 
once the claim was on the computer inside the company, the 40 
paper form could be dispensed with. Computerization is a 
highly effective way of reducing administrative overhead in 
claims processing. 

Thus, mainframe computers were purchased and installed 
internally at the insurance companies. Since these computers 45 
were intended for internal use only, each company thought 
only of its own needs and either developed proprietary 
claims processing software or had claims management soft- 
ware purchased from an outside source customized to meet 
the insurance company's claims processing methodology. 50 
While the claims management software for a number of 
insurance companies would be written in the same high- 
level programming language, e.g., COBOL, the similarity 
between software programs often ended there. 

There were many virtues to these early systems, primarily 55 
with respect to decreased administrative costs, but a major 
drawback was that the data for each "paper" claim had to be 
entered into the computer to form an electronic claim. This 
necessitated the manual transcription of exactly the same 
information that had been entered into the original paper 60 
claim before it was sent to the insurance company. 

(3) The next advancement was the electronic filing of 
claim forms. This was made possible by the introduction of 
the personal computer and modem into the provider's office. 
The main purpose of this stage was to eliminate the manual 65 
re-entry of information into the insurance company main- 
frame. 
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The basic idea was to have the providers fill out an 
electronic claim form, instead of a paper claim form. This 
electronic form, which would be stored in the memory of 
their PCs, would then be transmitted, as a computer file, to 
the insurance company. It could then be integrated directly 
into the electronic claims processing system without the 
manual re-entry of data. Thus, the technology existed to 
produce a system that computerized the overall filing and 
processing of the insurance claim from the point of entry, the 
provider's office, to the final report of the claims adjuster. 

Although the idea was straightforward, implementation 
was not. Two basic problems had to be overcome in order to 
create a viable system. First, the information contained in 
the electronic claim form had to be integrated into the claims 
processing software at the insurance company. Second, a 
majority of providers have to be able to interface with a 
majority of insurance companies, i.e., insurance company 
mainframe computers. However, because of the way com- 
puters were introduced into the insurance industry originally 
(stage #2), there was no industry-wide standard, i.e., the 
legacy mainframe computers of the different insurance com- 
panies were incompatible. This was true both with respect to 
the type of software used and with respect to the information 
that each company required on its claim form. 

One attempt to deal with these problems was the creation, 
by a consortium of insurance companies, of the National 
Electronic Information Corporation (NEIC). NEIC's basic 
function is that of a clearinghouse. It acts as a common 
interface between the insurance companies and the service 
providers. It also establishes rigid standards that must be met 
in order to transmit an electronic claim form to an insurance 
company. In practice, the service provider sends an elec- 
tronic claim to a vendor, who performs a service such as 
screening of the form. The vendor then transmits the form to 
NEIC, which then re-transmits it to the patient's insurance 
company. Since it is a computer file, the information in the 
electronic claim form can then be entered directly into the 
company's mainframe claims processing system, without 
the manual re-entry of data, and then processed. 

Thus, a coherent system was created that allows for the 
electronic filing, transmission, and processing of insurance 
claims. This system is employed by thousands of providers 
and hundreds of insurance companies. 

NEIC was designed to act as a clearinghouse for claims 
that are 100% text and that conform to very restrictive 
formats. For claims that meet these conditions it functions 
well, resulting in substantial savings on administrative costs 
for the insurance companies. It has been estimated that going 
to this third stage system results in savings of as much as 
60% in claims processing costs. 

However, there are many claims that do not meet these 
conditions. These would include claims that require addi- 
tional text information that does not fit into the prescribed 
format and/or claims that require non-text information. In 
general, these are called "claims with attachments." "Attach- 
ments" are any additional information that must be sent with 
the "standard text claim form." This could include: pictures, 
graphs, additional text not allowed on the standard claim 
form, sound recordings, etc. 

An example of such a claim would be the PAC (Prior 
Approval Claim), which may be alternately denoted as a 
"Pretreatment Claim." These are claims that are sent to the 
insurance carrier before a procedure is performed. For 
example, pretreatment claims are often required by dental 
insurance companies on any procedure over a specified 
amount, e.g., $200. The aspect of this type of claim which 
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renders it incompatible with the present electronic claim 
processing system is that the insurance companies require 
that additional medical evidence be included, i.e., attached 
to, the text part of the claim form. In an exemplary case, the 
additional medical evidence is an x-ray. 

The goal of the insurance company is to review the claim, 
i.e., both the text form and attachment, and to do so in a 
cost-effective manner. The natural next stage in the devel- 
opment of claims processing systems is to attempt to com- 
puterized this process. 

Scanners are now available that can digitize a dental 
x-ray, i.e., convert it into a computer file that can be viewed 
on a monitor. Nevertheless, transforming the medical evi- 
dence into digital form is not enough to facilitate electronic 
processing of claims with attachments. One must also take 
into consideration the existing claims processing 
infrastructure, i.e., the legacy infrastructure. 

The difficulty with trying to include a digitized x-ray for 
processing with an electronic claim form, within the current 
infrastructure, is multifaceted. First, NEIC does not at the 
present time allow this type of information to be transmitted 
through NEIC to the insurance companies. Second, with the 
current system, the claims adjusters access claims informa- 
tion through terminals connected to mainframes. However, 
there is the inherent problem of displaying images on 
mainframe computers. This is especially true of mainframe 
computers running software written in business program- 
ming languages such as COBOL. It might be thought that a 
solution to this problem would be to replace the terminal 
with a PC. Although many personal computers provide the 
graphics support needed to display the digitized x-ray, there 
are significant problems in interfacing a PC with a main- 
frame computer. For example, in order to interface with the 
mainframe computer, PCs often run terminal emulation 
software that permits the PC to act like a dedicated, dumb 
terminal attached to the mainframe computer. Terminal 
emulation software is notoriously lacking in graphics capa- 
bility. Finally, getting a digitized x-ray from one provider to 
one insurance company is not all that is needed. Rather, what 
is really needed is an industry-wide system by which a 
provider can interact with any insurance company. This 
results in a massive interfacing problem since there are 
multitudes of insurance companies using different legacy 
hardware systems and company unique software. 

Each time a way has been found to more fully utilize 
computers in claims processing systems, the administrative 
costs associated with claims processing have gone down. 
However, in the area of "claims with attachments/' no 
coherent industry-wide system exists that allows for the 
integrated filing, transmitting and processing of these claims 
electronically, i.e., via computers. Thus, when attachments 
are required, providers are forced to submit hard copy claim 
applications, while insurance companies labor under an 
administrative system that is a hybrid between a manual and 
an electronic system, i.e., a hybrid between stage #1 and 
stage #2. This hybrid system, which is described in greater 
detail below, is labor intensive, prone to problems, and slow. 
For providers, insurance companies, and patients, this is a 
time-consuming, costly and irritating process. 

In short, there is at least one type of insurance claim that 
has not, until now, been able to avail itself of the third stage 
of computerization, as described above. In fact, there are 
even difficulties with the second stage. This group includes 
any claim whose "standard text form" must be accompanied 
by additional information that does not fit into this standard 
format, e.g., x-rays, EKGs, additional text information such 
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as Operating Room Reports, etc. In general, these are 
referred to as "attachments." One primary example of this 
would be Prior Approvals for dental procedures. Prior 
Approval Claim (PAC) applications are those claims that are 

5 submitted for the purpose of receiving a predetermination of 
benefits from the insurance company for a procedure that 
has not as yet been performed. 

In the area of Prior Approval Claims, the goals of the 
insurance companies are to validate the necessity of the 

10 procedure and to determine whether the patient's insurance 
policy obligates the insurance company to pay for such a 
procedure. This requires that the insurance company itself 
review the medical evidence. For an insurance company's 
in-house dentist, for example, to make this appraisal, the 
dentist is required to review both the "text form" and the 
accompanying x-ray of the patient. However, the presence of 
a film x-ray means that electronic claims methods cannot be 
implemented. The savings associated with electronic claim 
processing is not available with respect to Prior Approval 

_ Claim forms. 

20 

Nationwide, there are approximately 200,000 dental 
PACs filed per week. Roughly, for every PAC application 
there will be eventually a Final Payment Claim (FPC) 
submitted when the medical procedure is completed. It is 

25 estimated that the overall administrative cost is $25 per PAC 
form and $10 for the Final Payment Claim. It is also 
estimated that if a coherent electronic system could be 
implemented, it would reduce these administrative costs to 
$15 per PAC and $5 per Final Payment Claim. The savings 

30 could amount to as much as $3,000,000 per week collec- 
tively for the health care industry for dental PACs and FPCs 
alone. 

An example of a hybrid system of claim processing 
currently in use will now be described with reference to 

35 FIGS. 1, 2A and 2B. 

Referring first to FIG. 1, the U.S. Postal Service, denoted 
as 100, connects the service provider's office 200 with the 
insurance company 300. It will be appreciated that, since 
PAC form handling is entirely manual at location 200, the 

40 service provider's office is depicted as lacking computer 
equipment. In contrast, the insurance company typically has 
at least one mainframe computer 350 to which terminals 
351, 352 on the respective reviewing dentist's and claims 
adjuster's desks are connected. It should also be noted that 

45 the mail room 320 is charged with a variety of tasks 
associated with the incoming and outgoing correspondence, 
as discussed in greater detail below. 

As will be appreciated from FIG. 1, a paper PAC form is 
filled out by the patient and/or the provider and, along with 

50 the substantiating x-ray, is mailed to the patient's insurance 
company. Upon entering the mail room of the insurance 
company, the PAC form is assigned a document identifica- 
tion number (DIN) and the data from the PAC form is then 
entered into the company's mainframe computer. This same 

ss DIN is affixed to the x-ray. The x-ray is then manually 
delivered to the reviewing dentist. 

By using the DIN on the x-ray, the reviewing dentist 
downloads, from the mainframe computer, the textual part of 
the patient's PAC application. The dentist makes a decision, 

60 records it in the memory of the mainframe computer, and has 
a hard copy of the Predetermination form posted back to the 
provider. Once the procedure has been completed, the pro- 
vider's office completes the Predetermination form, or fills 
out a separate Final Payment Claim (FPC) form. This is then 

65 posted to the insurance company. A chronological, detailed, 
step-by-step description of the hybrid system will now be 
provided with reference to FIGS. 1, 2A and 2B. 
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During step SI, the dentist decides that a costly procedure form, the form is saved to the memory of the insurance 

is necessary for a patient whose insurance carrier requires company's mainframe computer during step S27. The x-ray 

prior approval for such treatment. During step S2, the dentist is returned to the mail room during step S28. See task T4 in 

provides the patient with his diagnosis and gives the patient FIG. 1. 

an estimate for performing the recommended procedure. 5 Following approval, a paper copy of the Predetermination 

The dentist then asks the patient to contact his insurance form is made during step S29. See task T5 in FIG. 1. An 

carrier, or plan administrator at work, to obtain the necessary envelope is then addressed to the referring dentist and the 

PAC form. During step S3, the patient completes that portion Predetermination form is placed in the envelope during step 

of the PAC form that pertains to him, signs the form, and S30. During step S31, the corresponding x-ray is matched 

sends it to his provider. 10 with the Predetermination form and, during step S32, the 

After the PAC form arrives at the provider's office at step corresponding x-rays are placed in the envelope. The enve- 

S4, one of the office personnel retrieves the patient's file and lope then goes back into the U.S. Postal System 100 during 

the PAC form at step S5, extracts the patient's x-ray, either step S33. See task T6 in FIG. 1. 

the original, a copy of the original, or a second, previously Some days later, the envelope finally arrives at the den- 
taken x-ray, during step S6, and the PAC form is filled out 15 tist's office 200 and is opened during step S34. The results 
entirely by hand, i.e., the information about the provider has are noted in both the patient's paper file and computer file 
to be entered every time a new PAC form is received, during during step S35, the x-rays are returned to the patient's paper 
step S7. Copies of the completed form are made and are file at step S3 6, and the patient is notified of the approval and 
placed in the patient's file during step S8. The envelope a date is set for performing the approved treatment during 
containing the PAC form is addressed to the appropriate 20 step S37. 

insurance company at step S9. The form and the x-rays are treatment is completed during step S38 and the Final 

placed in the envelope during step S10. An entry is made in Payment Claim (FPC) form is filled out during step S39. It 

both the patient's computer file (if the provider's office is will be appreciated that the Final Payment Claim form, for 

equipped with one) and his hard copy file indicating that the many but not all msiirance companies, is merely a subsec- 

PAC form has been sent during step Sll and, finally, during 25 {[qd of (he p redeterminatiorl form generated in step S29 (See 

step S12, the envelope is mailed. See task Tl in FIG. 1. the paper denoted P* in FIG. 1.); alternatively, the Final 

The envelope meanders through the U.S. Postal Service Payment Claim form could be yet another form supplied by 

100 for several days at step S13 until the envelope finally the insurance company. 

arrives at the mail room 320 of the insurance company 300 Final Payment Claim form is then sent back to the 

at step S14. In the mail room, the envelope is opened (step insurance company with a copy of the signed Predetermi- 

S15), the data from the PAC form is entered into the nation form during step S40. See task T7 in FIG. 1. The Final 

insurance company's mainframe computer 350 and is given p ayme nt Claim form enters the mail room as a paper form 

a Document Identification Number (DIN) that identifies the and the fi nal processing begins during step S41. It will be 

patient and the current claim application (step SI 6). See task appreciated that the processing of the Final Claim Form 

T2 in FIG. 1. During step S17, the x-ray is labeled with the typically requires making several entries in the information 

same DIN. It will be appreciated that the DIN on the x-ray st0 red on the mainframe computer 350 and may require the 

and in the document now on the mainframe computer must preparation of one or more forms needed to authorize 

be identical. It will also be appreciated that for some pay ment of the final claim. However, since an attachment is 

insurance companies, this manual processing is contracted not normally associated with the Final Claim Form, addi- 

to an outside agency, which would require several more t i ona i discussion regarding disposition of the Final Claim 

steps, which steps will not be described further. Form within tne j nsurarjC e company will not be provided. 

During step SI 8, the x-ray is manually forwarded to the Thus, the hybrid system under discussion is one that starts 

reviewing dentist's area. See task T3 in FIG. 1. During step in the provider's office when a patient is told that a PAC 

S19, the PAC form is transferred to a directory and waits to 45 form is needed and continues until the procedure has been 

be read by a reviewing dentist. completed and a Final Payment Claim form has been 

During step S20, a group of x-rays arrives from the mail submitted to the insurance company for payment. It will be 
room at the reviewing dentist's area. A film x-ray is pulled appreciated that a myriad of problems and inefficiencies 
out of the waiting pile by the dentist during step S21 and the arise due to claim processing in accordance with the hybrid 
reviewing dentist then accesses the "PAC form" directory 50 system. The principal problems are as follows: 
during step S22 by, for example, reading the DIN from the 1. All information needed to complete the PAC form has 
x-ray and typing the DIN into the computer. The electronic to be entered by hand. Moreover, all of the information on 
PAC form corresponding to this x-ray is located in memory the PAC form is also manually transcribed in order to 
and downloaded to the reviewing dentist's monitor during transfer the information from paper to the insurance corn- 
step S23. 55 pany's mainframe computer. Both of these manual data 

The procedure requested is read off the terminal monitor entrv process steps are time consuming, very costly, and 

and the film x-ray is reviewed during step S24 and a prone to human error; 

determination is made during step S25. It will be appreciated 2. The x-ray film and the text form are put together and 
that a determination refers to either an approval or a denial then separated several times during the overall claim pro- 
of the request. Assuming that the procedure is approved, a 60 cessing; 

statement (or explanation) of benefits (EOB) is also gener- 3. The hybrid system requires that a hard copy of the x-ray 

ated. For the purposes of this discussion, it will be assumed be sent to the insurance company. Generally, this x-ray is 

that the procedure is approved; a denial would necessitate a returned to the provider. Moreover, the requirement that the 

parallel but alternative set of processing steps, which steps dentist provide the x-ray typically means that a duplicate 

will not be further described. During step S26, the insurance 65 x-ray has to be made by the dentist, which increases the 

company's Predetermination form is filled out either elec- dentist's cost for the service. Oftentimes, the duplicate x-ray 

Ironically or by hand. For an electronic Predetermination is of poor quality and cannot be read; 
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4. Because prior approval claim forms cannot be pro- 
cessed electronically, and because PAC forms make up half 
of all the claims that approximately 20,000 oral surgeons, 
periodontists, and orthodontists make each year, these 
20,000 providers have no compelling reason to initiate s 
electronic claims or Final Payment Claims; 

5. The document identification number is affixed to the 
x-ray and the electronic text in two different processes, one 
physical and the other electronic. This leads to errors; 

6. After the procedure has been completed, almost iden- 10 
tical information may again have to be entered by hand in 
order to prepare the Final Payment Claim form; 

7. While direct digital x-ray equipment is available, it is 
difficult to integrate a digital x-ray into the current hybrid 5 
claims processing system, i.e., these computerized images 
would first have to be transferred to film, which would, of 
course, negate the major advantage for using direct digital 
x-rays; 

8. Some insurance companies would like to require that 2 o 
x-rays accompany all dental claims; they are prevented from 
doing so because of the high administrative overhead asso- 
ciated with handling hardcopy claims; 

9. The patient has to obtain the PAC form from the 
insurance company or his employer. In either case, this 25 
causes the patient time, is an irritant, and imposes unnec- 
essary delays on the delivery of medical care to the insured; 

10. With the hybrid system, no pre-screening of the PAC 
form for errors is performed before the PAC form goes to the 
insurance company; and 30 

11. Provider information, i.e., the dentist's information, 
often has to be entered separately on each new PAC form 
that is submitted. 



In short, the current method for handling PAC applica- 



35 



tions is a hybrid system somewhere between a Stage 1, a 
totally paper-based manual processing system, and a Stage 
2 internally computerized insurance company processing 
system. It is part electronic and part hard copy. Also, each 
form must be handled twice, once as a hard copy and once 4Q 
as an electronic copy. This is the source of a great many of 
the above described problems. Moreover, the current hybrid 
method is costly. The process starting at the provider's 
office, continuing through the insurance company and finally 
to the return of the Predetermination form to the provider has ^ 
been estimated to cost $25. Furthermore, the whole process 
is filled with potential for error, frustration, wasted time and 
money. 

The workflow for the filing and processing of a PAC form 
was described above with respect to the dental health 50 
insurance which was used, by way of example, to illustrate 
the circuitous process involved when a hard copy attachment 
is present. Other types of claims, or attachments, or different 
insurance companies might require slightly different steps. 
For example, instead of returning an attachment, as describe 55 
above, the attachment might need to be microfilmed and 
archived, or some of the information contained in the 
attachment itself might need to be entered into the main- 
frame. Regardless of these differences, there are similarities 
in the problems that arise in processing such claims. 60 

In summary, in the insurance industry, payers and pro- 
viders exchange a great amount of information, which, in 
general, falls into two categories: 

1. Information flowing from the Payer to the Provider. It 
will be appreciated that this information can be further 65 
subdivided into additional types of information including, 
but not limited to information directly related to the Claim 



Application, e.g., content of the claim form or list of 
specified attachments needed to support a particular CPT 
code, general information, e.g., Preferred Provider List for 
specialists, etc., and responses to submitted claims, e.g., RFI 
on a claim sent. 

2. Information flowing from the Provided to the Payer. It 
will be appreciated that this information will generally be 
limited to Completed Claim Applications, e.g., AIC forms. 

It will be appreciated that the information specified by the 
payer as item (1) determines the information provided by the 
provider in item (2). It will also be appreciated that this 
information flow is further complicated by the fact that each 
of the various payers may have: 

1. Differing Claims Information Requirements, i.e., the 
information each payer requires is unique to that specific 
payer; 

2. Differing General Information, i.e., each payer has a 
respective unique set of preferred providers; 

3. Dynamic Information Demands, i.e., the information 
identified immediately above changes over time; and 

4. Different legacy system requirements, i.e., the provider 
generates a plurality of AIC forms, each going to a different 
payer in a payer specified format. 

As discussed above, the information flowing from the 
provider to the payer can be in one of several forms, 
including: 

1. Paper Claim Forms — These forms tend to have differ- 
ent content and to have the blanks for content arranged 
differently on the page. This leads to confusion and wasted 
time at the provider's office in completing the forms. 

2. Electronic Claim Forms — Because of the differing 
legacy computer systems and because of the confusion 
created by different forms, the current electronic solution 
takes the form of a rigid standardized electronic form based 
on truncated information. Stated another way, in order to 
optimize the cost savings of electronic forms, the payers are 
bound together in a rigid group where all must accept the 
limited information of a standardized electronic form and 
none can act independently to request more information be 
sent electronically. 

3. General Information — Information regarding preferred 
providers, etc., is currently available in hardcopy form. It 
will be appreciated that one hardcopy Preferred Provider 
List is very time consuming to use; the problem is exacer- 
bated when many Preferred Provider Lists must be main- 
tained. Even when this information is in digital form, there 
are still problems for providers because each payer has its 
own database and ways of searching for information within 
that database. 

What is needed is an electronic claim form instantiated by 
a Standard User Interface (SUI) which allows each provider 
to complete and then electronically transmit claim forms, 
which differ from one payer to another, to all payers. What 
is also needed is a dynamic claim form which permits each 
payer the freedom to independently determine the informa- 
tion content of its electronic claim form and to change that 
information, at will, over time. It will be appreciated that this 
latter requirement could be provide while, at the same time, 
maintaining the single multi -payer solution including the 
SUI. Thus, each payer can specify and later modify the 
information that it wants from all providers, while each of 
the providers always see and fill in the same form. What is 
also needed is a dynamic claim form which allows an 
individual payer to be readily selected by the provider. It 
would also be desirable if the dynamic claim form could 
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assist the provider in determining the information required 
by the selected payer. It will be appreciated that the enu- 
merated desirable characteristics permits overall system 
coherence (interoperability) yet independence for each 
payer. S 

SUMMARY OF THE INVENTION 

One purpose of the present invention is to create a 
coherent system that allows for the electronic filing, 
transmission, and processing of "insurance claims with 
attachments," and to thereby overcome the many deficien- 
cies of the hybrid system claims processing methodology 
described above. 

Thus, one object according to the present invention is to 15 
provide a PAC form processing system which minimizes the 
necessity of manual data entry. According to one aspect of 
the present invention, only about 40% of the information 
needed to complete the PAC form has to be entered by hand. 
According to another aspect of the present invention, the 20 
amount of information that has to be manually re-entered by 
an operator is essentially zero. 

Another object according to the present invention is to 
provide a PAC application processing system which elimi- 
nates handling errors resulting in a mismatch between, for 25 
example, a PAC form and an associated patient x-ray. 
According to another aspect of the invention, mismatch 
errors are virtually eliminated since the electronic x-ray and 
the associated text are never separated; field data included 
in, for example, the PAC form is copied and transferred 30 
between the server and the mainframe computer systems 
inside the insurance company. According to yet another 
aspect of the invention, mismatch errors are virtually elimi- 
nated since no hard copy of the x-ray is ever sent to the 
insurance carrier. 35 

Still another object according to the present invention is 
to provide a PAC application processing system which 
increases the number of service providers employing elec- 
tronic claims systems to thereby reduce the overall claims 
processing costs. Since a PAC form can now be handled 40 
electronically in accordance with the present invention, 
electronic final payment claims become viable for approxi- 
mately 20,000 additional dentists. 

A still further object according to the present invention is 
to provide a PAC application processing system in which 45 
Document Identification Numbers, or some other method of 
uniquely specifying the PAC, are simultaneously associated 
with both the text and the x-ray by a single computer entry. 

Yet another object according to the present invention is to 
provide a PAC application processing system which oper- 
ates at lower cost. Cost efficiencies are readily achieved 
according to the present invention by eliminating the need to 
send a physical x-ray with the claim. 

Another object according to the present invention is to 55 
provide a cost effective claim processing system wherein 
little or no information on either the PAC form or the 
Predetermination form has to be manually re-entered. 

Still another object according to the present invention is 
to provide a totally digital PAC application processing 60 
system which can accommodate both text and digitized 
x-rays at low cost, thereby allowing insurance companies to 
require x-rays with all claims because such requirements 
will not significantly increase the processing cost associated 
with non-x-ray documented claims. 55 

An additional object according to the present invention is 
to provide a totally digital PAC application processing 
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system in which a dynamic claim form, i.e., the PAC form, 
which addresses the needs of all insurance carriers, is stored 
in the memory of the computer in every service provider's 
office. Alternatively, this form could also be stored and 
accessed at an Internet website. This, in combination with a 
non-clearinghouse communications channel and having AIC 
system software at all of the insurance carriers, then elimi- 
nates the need for imposing industry-wide standards, such as 
ANSI ASC XI 2, for claim-related electronic transactions. 
The present invention allows each individual insurance 
company to obtain the information that it requires and to get 
that information in whatever format that insurance company 
prefers. Moreover, the ability to transmit the dynamic claim 
form and integrated attachment to an insurance carrier via a 
non-clearing house communications channel advanta- 
geously permits the transmission of other types of claims, 
including worker's compensation claims, to the insurance 
carrier. In addition, it will eliminate the irritant of the patient 
or provider having to obtain a PAC form from a particular 
insurance company. Finally, it will give the provider "time 
of service notification" of the needs of the payer. This, in 
turn, will drastically reduce the rate of claim rejection by the 
payer with the attendant necessity of re-review of a claim by 
the provider. 

Another object according to the present invention is to 
provide a totally digital PAC application processing system 
in which pre-screening of information entered into a PAC 
form, which is stored in the memory of the computer in the 
service provider's office, is easily performed. 

Yet another object according to the present invention is to 
provide a totally digital PAC application processing system 
in which provider information is automatically entered into 
each PAC form. 

It will be appreciated that none of the above-identified 
objects need actually be present in invention defined by the 
appended claims. In other words, only certain, and not all, 
objects of the invention have been specifically described 
above. Numerous other objects advantageously may be 
provided by the invention, as defined in the appended 
claims, without departing frotn the spirit and scope of the 
invention. 

These and other objects, features and advantages accord- 
ing to the present invention are provided by a standard 
graphical user interface (GUI) instantiated by computer 
software for generating a file from text data entered into 
selected ones of N fields in the GUI, wherein the selected 
ones of the N fields which accept text data are determined 
responsive to text entered into a first predetermined one of 
the N fields, and wherein N is an integer greater than 2. 
Moreover, the selected ones of the N fields is further limited 
responsive to text entry into a second predetermined one of 
the N fields. In an exemplary case, the first predetermined 
one of the N fields accepts a payer name while the second 
predetermined one of the N fields accepts a CPT code. 

According to another aspect, the present invention pro- 
vides combination of storage media storing computer read- 
able instructions for permitting non-networked computers to 
cooperate synergistically including a first storage medium 
storing computer readable instructions for permitting a first 
computer system to generate a form including N fields, to 
receive textual data as field data in selected ones of the N 
fields, to assemble the field data and a corresponding digi- 
tized attachment into a first file, and to transmit the first file 
to a second computer system via a communications channel, 
a second storage medium storing computer readable instruc- 
tions for permitting the second computer system to receive 
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the first file via the communications channel, to display the 
corresponding digitized attachment on a second screen of 
the second computer system, and to transfer the field data to 
a third computer operatively connected to the second 
computer, and a third storage medium storing computer 5 
readable instructions for permitting the third computer sys- 
tem to receive the field data from the second computer, to 
display the field data on a third screen of the third computer 
system and to generate a second file including portions of the 
field data extracted from the first file. Preferably, the selected 10 
ones of the N fields accepts text data are determined respon- 
sive to text entered into a first predetermined one of the N 
fields, and N is an integer greater than 2. 

According to yet another aspect, the present invention 
provides a method for operating a computer system includ- 15 
ing first, second and third computers, each of the first, 
second and third computers including a memory, an input 
device, and a display, respectively, the first and the second 
computers being connected to one another by modems and 
a common communication line, and the first computer 10 
including a digitizing device. The method advantageously 
includes steps for: 

(a) retrieving a first form including N fields from storage 
in the first computer's memory and displaying the first form 
on the first computer's display; 25 

(b) selecting M of the N fields responsive to text entry into 
a first predetermined of the N fields; 

(c) writing first field data to the first form using the first 
computer's input device; 3Q 

(d) digitizing a patient's x-ray to thereby generate a 
digitized x-ray; 

(e) combining the digitized x-ray and the first form so as 
to generate an attachment integrated file; 

(f) transmitting the attachment integrated file to the sec- 35 
ond computer; 

(g) transmitting the first field data from the second com- 
puter to the third computer; 

(h) generating a second form upon receipt of the attach- 
ment integrated file, the first and second forms containing at 40 
least a portion of the first field data; 

(i) displaying the first form, the second form and an image 
corresponding to the digitized x-ray on respective displays 

of the third computer and the second computer; ^ 

(j) writing second field data to the second form using the 
third computer's input device; 

(k) transmitting the first and second field data correspond- 
ing to second form back to the first computer, 

wherein M and N are both integers greater than 2, 50 
According to a still further aspect, the present invention 
provides a combination of storage media which store com- 
puter readable instructions for permitting Mx(NxR) non- 
networked computers to form a coherent system, including 
M first storage medium storing computer readable instruc- 55 
tions for permitting each of M first computer systems to 
receive textual data as field data, to assemble the field data 
and a corresponding digitized attachment into a first file and 
to transmit the first file to a selected second computer system 
and a selected third computer system via at least one 60 
communications channel, N second storage medium storing 
computer readable instructions for permitting the selected 
second computer system of N second computer systems to 
receive the first file via the at least one communications 
channel, and to display the corresponding digitized attach- 65 
ment on a second screen of the selected second computer 
system, and R third storage medium storing computer read- 
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able instructions for permitting the selected third computer 
system of R third computer systems to receive the field data 
of the first file via the at least one communications channel, 
and to display the field data on a third screen of the selected 
third computer system. Preferably, M, N, and R are each a 
positive integer greater than one, the selected second com- 
puter system and the selected third computer are selected by 
one of the M first computer systems responsive to address 
information included in the field data in the first file, and 
multiple items in the field data is selected by diagnostic code 
included in the field data. 

According to another aspect, the present invention 
encompasses a graphical user interface (GUI) instantiated by 
computer software for generating a file transmittable to a 
selected one of M recipients from text data entered into 
selected ones of N fields in the GUI, wherein the selected 
ones of the N fields which accept text data are determined 
responsive to text entered into a first predetermined one of 
the N fields, the computer software is updated as the 
respective file requirements of the M recipients change, and 
N is an integer greater than 2. 

According to a further aspect, the invention provides a 
graphical user interface (GUI) instantiated by computer 
software for generating a file transmittable to a selected one 
of M recipients from text data entered into selected ones of 
N fields in the GUI, wherein the selected ones of the N fields 
which accept text data are determined responsive to text 
entered into a first predetermined one of the N fields, the 
format of the file is determined responsive to text entered in 
the first predetermined one of the N fields, and N is an 
integer greater than 2. 

According to a still further aspect, the present invention 
encompasses a coherent computer system providing interop- 
erability between a plurality of independent computers. 
Preferably, the computer system includes a plurality of first 
computers, each of the first computers comprising a first 
storage medium storing computer readable instructions for 
permitting the respective first computer to: 

generate a form including N fields; 

receive textual data as field data in selected ones of the N 
fields; 

assemble said field data into a first file; and 
transmit the first file to a selected one of a plurality of 
second computers via a communications channel; and 
the second computers, each of the second computers 
comprising a second storage medium storing computer 
readable instructions for permitting the respective sec- 
ond computer to: 
receive said first file via the communications channel, and 
display said field data on a screen of the respective second 
computer. 

Advantageously, in the coherent computer system, the 
selected ones of the N fields which accept text data are 
determined responsive to text entered into a first predeter- 
mined one of the N fields, 

the selected one of the respective second computers is 
selected responsive to the text entered into the first 
predetermined one of the N fields, the computer read- 
able instructions stored on the first computers are 
updated responsive to changes to the selected ones of 
the N fields generated by a respective one of the second 
computers, and N is an integer greater than 2. 
According to yet another aspect, the present invention 
provides an electronic claim form instantiated by a Graphi- 
cal User Interface (GUI) which permits each of a plurality of 
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first users to complete and then electronically transmit N 
forms to N respective second users, wherein each of the N 
forms differs from the remaining N forms in terms of one of 
content and format. 

According to still another aspect, the present invention 5 
provides a dynamic electronic form which permits each of a 
plurality of first users to: independently determine the infor- 
mation content of its respective electronic form, and freely 
change the information over time. Preferably, the electronic 
form presented to each of a plurality of second users is 10 
constant, irrespective of changes to the information content 
dictated by a respective one of the first users. 

According to another aspect, the present invention pro- 
vides a dynamic electronic form accessible via a computer 
which provides a first user with the ability to freely select a 15 
second user from a plurality of second users, and which 
assists the first user in determining, assembling, and trans- 
mitting information specifically required by the second user, 
wherein the dynamic electronic form maintains a constant 
appearance irrespective of changes to required information 20 
established by any of the second users. 

These and other objects, features and advantages of the 
invention are disclosed in or will be apparent from the 
following description of preferred embodiments. 

25 

BRIEF DESCRIPTION OF THE DRAWINGS 

The preferred embodiments are described with reference 
to the drawings in which like elements are denoted by like 
or similar numbers and in which: 

30 

FIG. 1 is a combination high level block diagram and flow 
diagram which is useful in understanding the operation and 
attendant problems of the current hybrid system for Prior 
Approval Claim form processing; 

FIGS. 2A and 2B collectively form a flow chart which 35 
illustrates in greater detail the steps needed to implement the 
hybrid system of FIG. 1; 

FIG. 3 is a combination high level block diagram and flow 
diagram which is useful in understanding the operation and 
system of Prior Approval Claim form processing according 40 
to a preferred embodiment of the present invention; 

FIG. 4 is a detailed flow chart of the operational steps 
needed to operate the system illustrated in FIG. 3; 

FIGS. SAand 5B illustrate alternative embodiments of the 

45 

attachment integrated claim application according to two of 
the preferred embodiments of the present invention; and 

FIGS. 6A and 6B illustrate clearinghouse and non- 
clearinghouse networks, respectively, connecting service 
providers and insurance companies. 50 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

The present invention is a system and corresponding 
method implemented by software loaded onto the system for 55 
processing textual messages which are integrated with one 
or more attachments. Heretofore, such attachments could not 
be readily and/or usefully incorporated with the textual 
message. Hereinafter, the term Attachment Integrated Claim 
(AIC) Application will be used to denote a claim application 60 
including a text portion and a digital attachment portion. An 
exemplary embodiment of the present invention combines a 
patient's digitized x-rays with an electronic insurance claim 
form to create an electronic Prior Approval Claim (PAC) 
Application. Another preferred embodiment of the present 65 
invention is a coherent industry-wide system for the elec- 
tronic filing and processing of these PAC Applications. 
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It should be noted that the term "digital attachment" as 
used hereinafter is not limited to a digitized image or x-ray. 
The term "digital attachment" is understood to embrace 
x-rays, CTS, MIS, EKG or EEG recordings, i.e., strip charts, 
digitized video signals such as Moving Picture Experts 
Group (MPEG) compressed video signals, transcriptions of 
Operating Room Notes, estimates for repairs to a house or 
car, Explanation of Benefits (EOB), additional ASCII text, 
and the like. Moreover, all particulars regarding a specific 
"attachment/* such as medical specialty, acquiring modality, 
the patient's problem, etc., are to be ignored, since such 
details have absolutely no bearing on the various embodi- 
ments of the present invention. The only requirements 
regarding digital attachments are that the information must 
be something that can be digitized, i.e., put into the form of 
a computer file, and that once in this form, it can be "read, 
reviewed or interpreted" by the person or organization 
receiving it. 

The preferred embodiments according to the present 
invention will now be described with reference to FIGS. 3 
and 4. In particular, as shown in FIG. 3, the overall system 
according to the present invention includes the computer 
components 200 located in the health care provider's office 
and the computer components 300 located on the premises 
of the insurance company. Infrastructure 400, which advan- 
tageously may be an existing on-line service company, is 
preferably used in the exemplary embodiment of the present 
invention to facilitate communication between the compo- 
nents 200 in the service provider's office and the compo- 
nents 300 at the insurance company. Preferably, components 
500, which are located at a value-added service company, 
permit services ordered by the service provider, patient, or 
insurance company to be performed. It should be noted that 
the components 500 may duplicate a subset of the compo- 
nents 300 found at the insurance company and, for that 
reason, description of the components 300 alone will be 
provided below. 

It should also be mentioned that the description which 
follows describes the invention as it is used in connection 
with dental insurance forms. However, the present invention 
is not limited to systems for the processing of dental 
insurance claims. Rather, the present invention encompasses 
the preparation, transmission and processing of data pack- 
ages including a plurality of data fields wherein at least one 
of the data fields is a digital attachment, e.g., a digital image. 
For example, casualty insurance claims with supporting 
documentation, i.e., pictures taken with a digital camera, are 
within the scope of the present invention. In short, the 
present invention is advantageous in virtually all types of 
electronic data interchange (EDI) transactions. 

As shown in FIG. 3, the components 200 include a 
personal computer 210 including a screen 212, a keyboard 
214 and a modem 216, connected to a scanner 220, a printer 
230 and an archiving device 240, e.g., a large memory for 
storage of digital information. Device 240 advantageously 
may be a writeable compact disc read only memory (CD- 
ROM), i.e., a so-called write once — read many (WORM) 
device, a hard disk drive, a tape back up device or a 
removable hard disk device. It should be recognized that the 
computer 210 advantageously can be a computer system 
including a central processing unit, a graphic display 
processor, the graphic display device 212, and several 
memories including both solid state memories and a hard 
disk drive. It should also be noted that the archive device 240 
and one of the memories associated with computer 210 may 
be the same memory device. 

Components 300 located at the insurance company 
include the previously described mainframe or legacy com- 
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puter 350 and associated terminals 351, 352. In addition, a software stored in non-volatile memory on the service 

buffer computer 310, which may be a network server, provider's computer system 210, which software advanta- 

includes a modem 316 and is connected to a printer 330 and geously is Graphic User Interface (GUI) software, 

a storage device 340. The printer 320 may provide copies of Preferably, this AIC software is written in C++, Visual Basic, 

documents directly to the mailroom 320. Preferably, the 5 or some other appropriate graphical programming language, 

computer 310 is connected to personal computers or work [ t w ju be appreciated that commercial software packages, 

station terminals 311, 312 via a local area network (LAN) such as LOTUS NOTES™, have been designed with the 

313. The buffer computer 310 and the mainframe computer capability of addressing combinations of text and graphics 

350 are electronically connected to one another. The details files . However, the purpose of these packages is to create an 

of such a connection are well known to one of ordinary skill 10 "environment" or "platform" in which specific applications 

in the art and will not be described in greater detail. can be developed. In contrast, the preferred embodiments 

Before presenting a detailed description of other preferred according to the present invention are directed at providing 

embodiments according to the present invention, a brief integrated text and graphics files within a coherent system 

overview of the operating method steps associated with and methodology for addressing the specific needs of the 

formation, transmission and processing of the PAC Appli- 35 wor k fl 0 w, preferably of a particular industry. That is, it is a 

cation will now be presented. In an exemplary and non- particular application. It is possible, but not necessary, that 

limiting case, the essential steps of the operating method the software needed to implement the preferred embodi- 

include a first subroutine for completing and transmitting ments of the present invention can be developed within the 

needed information to a designated insurance company. This frame work of the environment created by something such 

subroutine includes steps for: 20 as LOTUS NOTES™. Alternatively, the software needed to 

(1) Retrieving the electronic PAC form, e.g., the dynamic implement the preferred embodiments of the present inven- 
claim form (DCF), from storage in the computer's memory tion can be developed using either JAVA™ applets or 
(or, in another exemplary case, from a website) and display- standard graphics markup language (SGML). 

ing the PAC form on the computer screen; Contained within the AIC software are PAC forms for 

(2) Filling out of PAC form on the computer screen; 25 insurance companies using the AIC system. When one of 

(3) Digitizing, e.g., scanning, the patient's x-ray; these is opened it acts as a template upon which a new 

(4) Combining the digitized x-ray and the electronic PAC computer file will be based. This computer file will uni- 
form into the patient's PAC application; and mately contain the patient's PAC Application. 

(5) Transmitting the patient's PAC application to the 3Q It will be appreciated that the PAC form when displayed 
designated insurance company. on the computer's screen 212 contains boxes, such as those 

After the PAC application is received by the insurance depicted in FIGS. 5A and 5B, in which alpha-numeric 

company, the insurance company performs another characters can be entered so that, when the characters are 

subroutine, which includes steps for: entered in these boxes they are entered so as to fill a "field," 

(6) Reviewing the PAC application; 35 a delimited alpha-numeric character string. Being a "field," 

(7) Generating an electronic Predetermination form when the information denoted by the characters can be transferred 
the application has been reviewed; and to ^ used in completing other fields in related documents. 

(8) Transmitting the electronic' Predetermination form ^ information itself, or lack thereof, can be used as 
back to the insured's Service Provider. a lo & c contro1 device > e 'S-> used to remind preparer that 

When the electronic Predetermination form from the 40 critical information has not been entered, 

insurance company is received by the service provider, an In ^ e e * em plary case being discussed, the PAC forms of 

additional subroutine is performed by the service provider. man y instance companies have been encoded and stored in 

This subroutine advantageously includes steps for: memory on the service provider's computer system 210. 

(9) Reading the electronic Predetermination form; ^ can be advantageously done in the following way. The 

(10) When the approved procedure has been performed, 45 ^ forms for * U ^teurance companies using the AIC 

adding completion data to the electronic Predetermination Systcm * rc g " thercd A ™ en a um0I \ of A ^ * c . ^™*>a 

form and requested in these PAC forms is made. A field is created for 

*t- * * j i * ' n j * . each element of information requested. For example, Field 

(11) Transmitting the annotated electronic Predetermina- W1 t . *■ ^ « * r - u jw * • lL 

v / , . 4 x t ^ #1 contains the patient s first name, Field #2 contams the 

tion form back to the Insurance Company. *■ *» i * j t-l* • j 

___ , , t . _ *, J . , „ . so patient s last name, and so on. This is done until the 

When the annotated electronic Predetermination form is ' "information fields" of the PAC forms for all of the insur- 

received from the service provider, the insurance company mce companies are mc i ud ed. 

performs a final subroutine, which includes steps for: T . . . L • 

/■ti\n • • al a a j • c > • . In order to mcrease the efficiency of the clerical staff at the 

2 Reviewing the annotated information; and provider's office, it is desirable to give them basically the 

(13) Issuing the final payment to the service provider. 55 same form t0 fi „ QUt every ^ { ^ information is always 

The method for operating the system according to a j n me same place on the form. To do this a template is 

preferred embodiment of the present invention will now be created. What actually appears on the screen of the preparer 

described in detail. ^ ai wa y S the same. What changes is that any given insurance 

The method starts at step S101 with the service provider's company will desire only a particular subset of the total 

diagnosis that a costly procedure is necessary. It is then 60 number of fields. So if insurance company A is chosen, then 

determined that the patient needs prior approval from his fields 1,2,3,7,9, . . . have to be filled in, whereas, if insurance 

insurance company. During step S102, the patient is pro- company B is chosen, then fields 2,3,4,5,7,11, . . . have to be 

vided with an explanation of the procedure and a cost filled in. The fields not needed are automatically signified in 

estimate for that procedure. The service provider and the some way by the AIC software, e.g., if insurance company 

patient then prepare the needed PAC Application. 65 A does not need Field #4 then that block on the screen is gray 

During step S103, a member of the service provider's and can't be typed into (i.e., is "write protected"). Thus a 

office staff accesses the Attachment Integrated Claims (AIC) "customized claim form" is provided for every insurance 
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company based on a single, universal compilation of fields. case, the patient's x-ray may be digitized before the PAC 

As described below, what allows this method to work is that form is called up on the computer screen 212 and completed, 

there is AIC software at the insurance company that has been During step SI 05, the PAC application is formed from the 

coordinated with the AIC software at the providers office. electronic PAC form and the digitized patient's x-ray. It 

The AIC Software GUI asks for the name of the insurance 5 should be noted that the present invention is not limited to 

company, which can be typed in or selected from a directory. a particular format for the PAC application. For example, the 

Once the insurance company has been identified, the fields format of the PAC application advantageously may consist 

needed to complete the insurance company's PAC form are of a text file and an associated digitized image file. It should 

displayed on the screen 212 of the service provider's com- be noted that in one case the text and image files will be 

puter system 210. The AIC software advantageously can 1Q transmitted seriatim. For that reason, the text file (i.e., the 

automatically fill in all the parts of the form that are specific PAC form) and the image file (i.e., the digitized x-ray) must 

to the service provider, e.g., name, address, Provider Iden- cross reference one another (i.e., be correlated) so that these 

tification Number (PIN), etc. It is estimated that this alone files can be continuously associated with one another after 

eliminates 20% of the work needed to fill out the PAC form. transmission to the insurance company. If the attachment is 

An electronic signature could advantageously be added at simply additional ASCII text, e.g., Operating Room Notes, 

this time for the service provider or could be added as part then the only step necessary is to transfer the additional 

of the final review and approval before the completed PAC ASCII text into the integrated file format. Once in the 

application is transmitted. integrated file format, all processing is the same as if the file 

Needed patient information is then entered into the PAC contained an image attachment, 

form on the computer screen 212, preferably while the 2Q In an alternative exemplary case, the PAC application 

patient is still in the office, and a provider Document advantageously can be prepared according to the Graphic 

Identification Number (PDIN) can be used to label the form, Interchange Formats (GIF) specification, which specifica- 

if so desired. This is now a computer file identified as tion is the intellectual property of CompuServe Incorpo- 

referring to the patient. It should be noted that some form of rated. In order to form the PAC application, the digitized 

signature can be provided in the appropriate field. As an 2j x-ray is converted to a GIF image file. It will be appreciated 

example, a special electronic pad and pen can be used such that the GIF image file advantageously can include one or 

that when the patient signs on the pad his signature is affixed more blocks of textual data denoted by a comment 

to the electronic PAC form. extension, as described in Version 89a of the GRAPHICS 

It will be appreciated that, for example, the patient INTERCHANGE FORMAT documentation published by 

identification number (patient ID) from the service providers 30 CompuServe, Inc. It should be noted that since the textual 

own data base advantageously can be used to access patient information corresponding to the data needed to complete 

specific information that the AIC software can insert into the the PAC form is included in the GIF image file comments, 

PAC form, i.e., the DCF. Moreover, it will also be appreci- the possibility of file separation and consequent mishandling 

ated that the CPT code for a procedure could be keyed in to or mismatching of the separate components of the PAC 

further differentiate the DCF. For example, if the CPT code 35 application is virtually eliminated. Alternatively, the TIFF 

is associated with the requirement for an X-ray by a par- standard format advantageously can also be used to co-join 

ticular payer, the DCF will identify the need for an X-ray field and digital image data. 

attachment to the service provider. Moreover, the CPT code It will also be appreciated that the concept of embedding 

advantageously can be employed to further differentiate the comments into the GIF or HFF image file format is a 

DCF to, by way of a non-limiting example, provide a list of 4Q standard practice employed by those of ordinary skill in the 

Preferred Providers that the particular payer has pre- art of graphic image preparation, e.g., by photographers and 

approved for service providers wishing or needing to refer digital artists who wish to identify their works. However, it 

the CPT code-identified procedure to a specialist. should also be noted that the use of a comment block storing 

During step S104, the patient's x-ray is digitized. In an data fields used in reconstructing a completed form, e.g., a 

exemplary case, there is a scanner 220, i.e., digitizer, con- 45 completed PAC form, has never before been described or 

nected to the service provider's computer system running suggested. Furthermore, since the technique described 

the AIC software. The patient's x-ray is scanned and con- above is a novel solution to electronically forwarding an 

verted into a series of ordered numbers (i.e., a bit map of the insurance claim form and an associated attachment as one, 

x-ray image) and stored. It should be noted that these stored the use of the comment block to store the PAC form field 

series of numbers can be reconstructed by the computer 50 data is likewise a unique and novel aspect according to the 

system to display the x-ray on a computer monitor, i.e., the present invention, 

bit map can be used to reconstruct a raster image of the x-ray In yet another alternative exemplary case, the digitized 

for display. x . ra y ^ automatically added (inserted) to the electronic form 

It will be appreciated that the AIC software advanta- by the service provider's AIC software and forms a single 

geously can be written to minimize the time needed to scan 55 computer file, as depicted in FIG. 5B. It should be noted that 

the x-ray. In an exemplary case, the operator can specify the the non-text portion of the PAC application is labeled with 

type of x-ray or x-rays that are being scanned. This is done the same provider Document Identification Number (DIN) 

so that blank areas are not being digitized and added to the as used on the text portion, i.e., the electronic PAC form, 

patient's file. It will be noted that this will also save on These two objects together now form the patient record, i.e., 

transmission time to the insurance company. Further, as will <so the patient's PAC application. The PAC application is now 

be readily appreciated by those skilled in the art, the text and ready to be sent to the insurance company, 

image data comprising the file can be encoded and com- During step S106, the service provider's office staff then 

pressed in any manner well known in the art in order to transmits the completed PAC application to the insurance 

minimize data storage and transmitting claimed require- company. For example, when the transmission icon of the 

ments - 65 GUI AIC software running on the service provider's com- 

It should also be mentioned that steps S103 and S 104 need puter system 210 is activated (e.g., "clicked" on), the 

not be performed in any particular order. In an exemplary following subsets are automatically executed: 
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(a) A check is first performed to ensure that the PAC 
application has been completely filled out. In the event that 
problems and/or errors are noted by the AIC software, the 
system user is notified of the error by an appropriate 
annunciator, e.g., the suspect area can be highlighted and a 5 
message concerning the problem and/or error could be 
generated and displayed on the monitor; 

(b) A hard copy of the PAC application is printed out, if 
desired, by the service provider. The hard copy may advan- 
tageously be placed in the patient's permanent file; 10 

(c) Moreover, and more importantly, the completed PAC 
application is archived in the service provider's computer 
system 210, 240. It will be appreciated that this archive copy 
can be accessed in several ways such as by patient name, 
social security number, document identification number, etc. 15 
That is, it can be accessed using any of the information that 
has been entered into the PAC form; and 

(d) The service provider's computer system establishes a 

connection with the on-line service 400 and transmits the _ 

20 

patient's PAC application to the insurance companies e-mail 
address. See task Tla of FIG. 3. It will be appreciated that 
the e-mail addresses of all the insurance companies have 
been stored in the AIC software residing in the memory of 
computer system 210. In short, the e-mail address is iden- 
tified when the name of the payer, i.e., the insurance 
company, is identified in the DCF. Advantageously, the PAC 
application can be transmitted immediately or can be sched- 
uled for transmission at a convenient time, i.e., can be 
transmitted after all of the PAC applications and other forms 3Q 
have been prepared for the day. Preferably, the AIC software 
on the service provider's computer system 210 keeps a 
record of when the PAC application was sent. In addition, 
the AIC software maintains and uses the proper protocols so 
that when the PAC application reaches the intended insur- 35 
ance company, it arrives there with the alpha-numeric por- 
tion of computer file intact, i.e., the information is stored in 
fields that can be read by the corresponding AIC software 
module in the computer system 310 at the insurance com- 

Pany ' . ... . 40 

It should be noted that the specific transmission path taken 

by the PAC application from the service provider's computer 

system 210 to the computer system 310 maintained by the 

insurance company is not an essential limitation of the novel 

system and corresponding operating method according to a 45 

preferred embodiment of the present invention. The only 

requirement of a transmission path is that it maintain the 

digital integrity of the PAC application computer file. Thus, 

the patient's PAC application can be sent to the insurance 

company in several ways using modems 216 and 316, 50 

including via normal phone service, an on-line service, or 

bulk data transmission lines. 

In an alternative exemplary case, the completed PAC 
applications may even be transferred to tape or CD-ROM 
and then sent through the U.S. Postal Service 100 of FIG. 1 55 
to the insurance company's mailroom 320. For purposes of 
the discussion which follows, only the exemplary case in 
which the PAC application is transmitted via the on-line 
service 400 is described in any detail. 

One of the beneficial aspects of the present invention is 60 
provided by the combination of the dynamic claim form on 
the service provider's computer 210 and the use of any 
non- restrictive communications channel, i.e., the insurance 
companies are able to freely modify information require- 
ments demanded of the service providers. Existing elec- 65 
tronic claims processing systems, such as NEIC, are based 
on a clearinghouse concept, as illustrated in FIG. 6A. In a 
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clearing house system, all claims enter the clearinghouse 
computers), are manipulated, and then are transmitted to the 
appropriate insurance company. One consequence of the 
clearinghouse architecture is that it puts a constraint on the 
insurance company to use a standardized claim form. The 
individual insurance companies have little or no control of 
the information content in the form. Moreover, because the 
claim form is standardized, changes are very difficult to 
make, i.e., any change requires that all member insurance 
companies make the change together. 

In contrast, placing AIC software packages in the provid- 
ers' offices and in the insurance company processing centers, 
[these packages are coordinated with one another, but not 
identical to one another], allows every payer to transmit 
claim form updates to every provider. In the provider's 
office, the change would be reflected primarily in changes to 
the number of fields needing information and, rarely, in the 
addition of a new field to be completed by the provider. It 
will be appreciated that the AIC software could check for 
updates, and download any update located, during the PAC 
transmission described in detail elsewhere in this specifica- 
tion. Alternatively, all payer-specific updates to the DCF 
could be centralized on a single server, so that the service 
providers could check for all updates from all payers when- 
ever the service provider transmits a completed DCF to any 
single payer. Moreover, the blank DCF templates advanta- 
geously could be accessed at an Internet website for either 
downloading or completion by the providers. 

As illustrated in FIG. 6B, the interchange between the 
provider's office and the insurance company(ies) advanta- 
geously can be performed using an online service or Internet 
Service Provider (ISP), providing that the service provider 
permits 8-bit file interchanges. In that case, the update 
information could be transmitted to the provider when the 
provider dials into the online service. Thus, while it is true 
that transmission accomplished using e-mail involves an 
intermediary computer, the online service merely provides a 
mail box and places no conditions on the insurance infor- 
mation contained in the claim itself. 

Advantageously, the non-clearinghouse architecture and 
coordinated AIC software package, along with periodic 
updates, facilitates the provision of the dynamic claim form. 
That is, each insurance company can determine the content 
of its own claim form. The packages used by the providers 
are instructed regarding the information content, protocols, 
etc. each insurance company wants its claim to have. It will 
be appreciated that the package at each insurance company 
is designed to accept only those claims that meet the 
specifications of the respective insurance company. In 
addition, if an insurance company wants to change the 
content of its claim form, it can do so independently of the 
other insurance companies. In summary, the above combi- 
nation maintains interoperability throughout the industry 
even while it allows information requests to change. 

Beneficially, the non-clearinghouse architecture reduces 
costs, allows for the direct digital interchange of data from 
one insurance company to another, and permits many dif- 
ferent types of forms to be run off the same system, e.g., 
commercial insurance claims and workers' compensation 
claims can both be processed in the provider's office using 
the same dynamic claim form. This produces a claims 
processing system which is more robust than anything on the 
market today. 

During step S107, the PAC application is pre-processed 
by the value-added service provider 500. For example, the 
patient's PAC application can be accessed by the employees 
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of the value-added service company to perform services for 
either the patient, the service provider, or the insurance 
company, or any combination thereof. See task T2 of FIG. 
3. These value-added services could include archiving of the 
patient's dental x-rays so that all records for a particular 
patient are centrally stored, screening of the entire PAC 
application for errors, compiling statistics on all PAC appli- 
cations and, in some instances, even performing the review 
process for the insurance company. 

Next, the insurance company accesses the PAC applica- 
tions at the on-line service during step SI 08. In an exem- 
plary case, each insurance company has an E-mail address 
specifically for the purpose of receiving PAC applications. 
An insurance company accesses its E-mail box and finds a 
waiting list of PAC applications which are subsequently 
downloaded to GUI-capable computer system 310. In a 
preferred embodiment as shown in FIG. 3, the GUI-capable 
computer system 310 advantageously is connected to the 
claims management mainframe computer 350 of the insur- 
ance company 300. Preferably, the GUI -capable buffer com- 
puter system 310 is a personal computer (PC) or a PC server 
which advantageously can be operated in parallel with but 
separate from the insurance company's mainframe computer 
350; data, however, beneficially can be interchanged 
between the buffer computer system 310 and the mainframe 
computer 350. In an exemplary case, as the personnel at the 
insurance company 300 apply an insurance company docu- 
ment identification number (DIN) to each received PAC 
Application, the field data contained therein is copied by the 
buffer computer system 310 and transmitted to the main- 
frame computer 350. See task 71b of FIG. 3. 

Alternatively, the entire PAC application advantageously 
could be copied by the buffer computer system 310 and 
downloaded to the mainframe computer 350, where the 
image portion of the PAC application then can removed 
from the mainframe's memory. This approach employs 
basically the same distribution of information, i.e., text form 
in the mainframe 350 and field data and images in the buffer 
computer system 310. 

In an exemplary case, this buffer computer 310 is part of 
a local area network (LAN) 3 13, which is connected by high 
bandwidth cables to personal computers or other GUI- 
capable terminals 311, 312 at the desks of the individual 
reviewing dentists and claims adjusters, respectively. It 
should be noted that the necessary AIC software has been 
loaded onto the server 310, the individual personal comput- 
ers 311, 312, and the mainframe 350. Preferably, once the 
patient's PAC application has been received, the system's 
AIC software at either the value-added service provider 500 
or the insurance company's computer 310 automatically 
notifies the referring service provider that the PAC applica- 
tion has been received for processing, e.g., using a conven- 
tional E-mail message. 

At step S109, the reviewing dentist calls up the graphics 
portion of the PAC application, in an exemplary case, from 
the server 310 to a personal computer 311, each of which is 
running the appropriate AIC software, via the LAN 313 
using the assigned DIN. See task T4 in FIG. 3. The review- 
ing dentist then calls up the text portion of the PAC 
application from the mainframe computer 350 using the 
terminal 351. It will be appreciated that the sequence can be 
reversed at the reviewing dentist's option. It should be noted 
that some small insurance companies may not even require 
server-LAN 310, 313 system discussed above, but just a 
single PC that will incorporate the functions of the elements 
310, 311, 312, and 313. In any event, the reviewing dentist 
calls up a patient's PAC application using both his personal 
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computer 311 and terminal 351. When this happens, the 
system AIC software automatically generates the insurance 
company's Predetermination Form on one of the two screens 
311, 351. The installed AIC software advantageously can 

s automatically transfer whatever information from the PAC 
application to the Predetermination form that is useful in 
completing the Predetermination form, e.g., repetitive 
information/fields. For instance, the service provider's 
Document Identification Number (PDIN) and the Provider 

10 Identification Number (PIN) can be transferred automati- 
cally to the Predetermination form. In addition, the AIC 
software can be written to display the information in the 
PAC form on the screen 351 in exactly the way that this 
particular insurance company wants it displayed. 

15 In a alternative implementation, a single monitor on the 
computer 311 supporting multiple windows, at least one of 
which runs terminal emulation software for displaying the 
output of the mainframe computer 350, could advanta- 
geously be used to display both parts of the PAC application. 

20 With the AIC system described above, the use of "fields," 
the dynamic claim form, and the placing of coordinated AIC 
software at both the service provider's office and the insur- 
ance company, has eliminated the need for standardized 
forms. The result is that each insurance company gets 

25 exactly the information it wants and has it displayed in 
exactly the way it wants. Thus, the compromise of a stan- 
dardized claim form as is required with the present NEIC 
system is avoided. 

30 In an exemplary case, the reviewing dentist is provided 
with three monitors or a large graphics-capable monitor 
having a multi-page display mode, on which can be dis- 
played the three pages of the patient file. It will be appre- 
ciated that this configuration is optimized to facilitate rapid 

35 review of the PAC application. The reviewing dentist enters 
an Insurance Company Document Identification Number 
(DIN) at this point, which number is affixed to all three 
pages of the patient's file. 

During step S110, the reviewing dentist reviews the PAC 

40 application. More specifically, the review process consists of 
a review of the medical facts or evidence (i.e., the text and 
x-ray information in the PAC application), as well as a 
review of the patient's insurance policy. Once the reviewing 
dentist has made his analysis, he goes to the Predetermina- 

45 tion form, i.e., the third page, and enters the required 
information to either approve or disapprove the procedure 
during step Sill. The specific details regarding the infor- 
mation provided by the reviewing dentist will depend on the 
procedures established at each individual insurance com- 

50 pany. Either the reviewing dentist or another person, e.g., a 
claims adjuster, will do the review of the patient's insurance 
policy. 

Advantageously, there are several ways to gain access to 
this information. First, the server 310 can have information 

55 on every policy holder loaded into its memory. Second, the 
benefits reviewer, i.e., either the reviewing dentist or the 
claims adjuster, can have another monitor 351, 352 on his 
desk that is connected to the company mainframe computer 
350. Thus, all that the benefits reviewer must do is select the 

60 patient's insurance ID number and his benefits sheet will 
appear. The benefits reviewer then reads off the information 
that must be entered in the Predetermination form and enters 
the information into the either the GUI-capable computer 
system 310/311/312 of the mainframe computer 350 during 

65 step Sill. It should again be noted that there is an electronic 
connection, in the preferred embodiment, between the main- 
frame computer 350 and the server 310. Whatever informa- 
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tion is deemed necessary by that particular insurance com- 
pany to complete the Predetermination form can be 
transferred between the mainframe computer 350 and the 
buffer computer system 310 by entering data on one of the 
terminals 311, 351. See, for example, task T5 in FIG. 3. 

At this point, the Predetermination form is ready to be 
sent to the referring service provider. When the transmit icon 
on the computer screen of the benefit reviewer's GUI- 
capable computer system 311, for example, is activated 
(e.g., by being "clicked" on), the following substeps are 
automatically performed: 

(a) First, a check is performed to verify that the Prede- 
termination form has been completely and properly 
filled out. If errors are detected, the AIC software 
notifies the operator via an appropriate annunciator; 

(b) The Predetermination form and the patient's PAC 
application are downloaded to the buffer computer 310. 
See task TSa. From this platform, the company 
accesses the on-line service 400 and transmits the 
Predetermination form, i.e., just the information 
"fields", to the service provider's e-mail address, which 
is stored in the memory of server 310. See task T6. In 
the AIC software, records are kept as to which PAC 
applications have been sent and when and to whom. 
The proper protocols are used so that when the appli- 
cation reaches the service provider, it arrives there as a 
computer readable file, i.e., the information is stored in 
"fields" that can be read by the AIC software at both the 
insurance company and the service provider's office; 

(c) A hard copy of the Predetermination form and x-ray 
are printed, if desired, by the insurance company, see 
task T7; 

(d) The complete patient file is archived in the insurance 
company's computer system 310, 340, if desired. See 
task T8. Otherwise, just the electronic Predetermina- 
tion form and the PAC application are saved; and 

(e) The entire three page patient file is now cleared from 
the reviewing dentist's displays 311, 351 and the AIC 
software prompts the reviewing dentist as to whether 
another patient file should be accessed. 

During step S112, the service provider accesses his e-mail 
address with the on-line service 400. All Predetermination 
forms which have been received are automatically delivered 
to the service provider's computer system 210 for insertion 
into the appropriate patient file. The service provider then 
reviews the Predetermination forms. Upon evaluating the 
decision of the reviewing dentist, the service provider can 
either perform the procedure (if approved) or discuss the 
matter with the patient's insurance company (if not 
approved). 

During step S113, the approved procedure is performed 
by the service provider. Once the approved procedure has 
been completed, the service provider preferably sends in the 
Final Payment Claim (FPC) form. In an exemplary case, this 
could be as simple as just filling out another section of the 
Predetermination form and signing it using the electronic 
signature pen, as discussed above. It should be noted that in 
FIG. 3, this is labeled as P* . Alternatively, if the insurance 
company so desires, a separate form just for this purpose can 
be employed. This latter form, which advantageously is the 
same dynamic claim form discussed above, is stored in the 
memory of the provider's computer, must have the Insur- 
ance Company's DIN for this particular patient's procedure 
and all other needed information transferred to it, which 
advantageously can all be done by the AIC system software 
at step S114. At step S115, the Final Payment Claim form is 
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transmitted back to the insurance company. See task T9 of 
FIG. 3. In an exemplary case, activating the transmit icon on 
the service provider's computer system 210, e.g., by "click- 
ing" on it, automatically results in the execution of the 
5 following substeps: 

(a) A check is performed to see that the form has been 
completely and correctly filled out. If an error has 
occurred, the AIC software alerts the operator of the 
detected error; 

1 o (b) A hard copy of the form is printed out, if desired, by 
the service provider; 

(c) The complete patient's electronic file is archived in the 
service provider's computer system 210, 240. It will be 
noted again that the patient's electronic file can be 

15 accessed by patient name, social security number, 
document identification number, etc.; and 

(d) The computer system 210 establishes a connection 
with the on-line service and transmits the patient's 
Final Payment Claim (FPC) form to the insurance 

20 company's e-mail address. 

As previously discussed, the AIC software on the service 
provider's computer system 210 advantageously may 
include facilities for transmitting the Final Payment Claim 
form to the insurance company at a later time, e.g., for 

25 transmitting all of the days PAC application and FPC forms 
at one time. 

It will also be noted, as discussed above, that the AIC 
software maintains records as to which claim form was sent 
and when it was sent to the insurance company. In an 

30 exemplary case, the E-mail address to which the Final 
Payment Claim form is sent is different from the address 
used in transmitting the PAC application. Since the Final 
Payment Claim form does not include a digitized image, i.e., 
a digitized x-ray, the insurance company may choose to have 

35 the Final Payment Claim form directed to an E-mail address 
accessible from the mainframe computer 350. If the insur- 
ance company's processing protocol requires an indepen- 
dent review of the PAC application, the Predetermination 
form and the Final Payment Claim form before payment can 

40 be authorized, the E-mail address advantageously can be 
accessed from either the server 310 or the mainframe 
computer 350, since these two computer systems are elec- 
trically coupled at the insurance company 300. 

The insurance company then receives the Final Payment 

45 Claim forms during step S116 when it accesses its Final 
Payment Claim forms mail box. In an exemplary case, the 
computer system receiving the Final Payment Claim forms 
is not the claims management mainframe computer 350 of 
the insurance company but, rather, it is a personal computer 

so or server 310 that is part of a parallel system having an 
electronic connection to the mainframe computer 350. This 
buffer computer 310 advantageously can be part of a LAN 
313. The buffer computer 310 is connected by high band- 
width cables to the personal computers or GUI-capable 

55 terminals 312 located at the claims adjusters' s desks. See 
task T10. It should again be noted that the appropriate AIC 
software modules have been loaded onto both the server 
310, the personal computers 312 and the mainframe com- 
puter 350. It will be appreciated that the information entered 

60 in computer 312 advantageously can be automatically trans- 
ferred to the mainframe 350 through the transmission path 
including the computer 312, the buffer computer 310 and the 
electronic connection to the mainframe computer 350. 
The Final Payment Claim form is then reviewed during 

65 step S117. The adjuster reviewing the Final Payment Claim 
form can, if necessary, call up the PAC application from the 
memory of the server 310, since the original Insurance 
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Company Document Identification Number for the corre- 
sponding PAC application was transferred to the Predeter- 
mination form and, thus, to the Final Payment Claim form. 
In addition, the adjuster can, if need be, call up the infor- 
mation on the insurance policy of the particular patient 
stored in mainframe computer 350 via terminal 352. 
Preferably, the insurance company provides the adjuster 
with a separate monitor 352 connected to the claims man- 
agement mainframe computer 350. 

Whatever internal paperwork is necessary to be filled out 
is automatically downloaded with the Final Payment Claim 
form itself by the appropriate AIC software module. Part of 
this paperwork will preferably be form(s) which must be 
completed so as to order a check issued to the service 
provider along with an Explanation of Benefits (EOB). Also 
at step S118, whatever information is necessary to be entered 
into the mainframe 350 can be entered directly through the 
use of the terminal 352 or indirectly through computer 312, 
the buffer computer 310 and the electronic connection to the 
mainframe computer 350. 

Finally, upon activating the transmit icon on the insurance 
company's personal computer 312, for example, the follow- 
ing substeps are automatically executed: 

(a) A check is again performed to see that the form has 
been completely and correctly completed and the 
operator is notified if an error has occurred; 

(b) A hard copy of the form is printed out, if desired by 
the insurance company; 

(c) The complete patient file is archived in the insurance 
company's computer system, e.g., on the server. It 
should again be noted that the patient file can be 
accessed using the patient's name, social security 
number, or an assigned document identification 
number, etc.; and 

(d) A payment draft is issued, in the approved amount, to 
the service provider. This can be done through any 
number of methods, including printing a hard copy 
check and forwarding it through the U.S. postal service, 
electronic funds transfer, etc. Each form of payment 
will be accompanied with the normal description of the 
service to which these funds should be applied, i.e., the 
EOB (Explanation of Benefits). 

The preferred embodiment was described as transmitting 
digitized dental x-rays as part of an integrated PAC appli- 
cation file transmitted between a service provider and an 
insurance company. However, the present invention is 
broadly directed to the integrated transmission of any "elec- 
tronic text form" and any "attachment." Further, the present 
invention is not limited to transmissions between providers 
and insurance companies. Rather, it is intended to facilitate 
the transmission of electronic forms with attachments 
between any person or organization and any other person or 
organization. 

For example, the present invention has utility in such 
other areas as Property/Casualty Insurance, law 
enforcement, and Internet marketplaces. Thus, the "attach- 
ment" need not be an x-ray or other type of image. Rather 
it can be any information which is not easily incorporated 
into an associated "electronic text form" and/or cannot be 
easily displayed on an existing legacy computer system. 
Attachments can include, but are not limited to, pictures, 
graphs, sound recordings, and nonstandard text. Examples 
would be x-rays, CTS, MIS, EKG or EEG recordings, i.e., 
strip charts, digitized video signals such as Moving Picture 
Experts Group (MPEG) compressed video signals, tran- 
scriptions of Operating Room Notes, estimates for repairs to 
a house or car, EOB (Explanation of Benefits), additional 
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ASCII text, and the like. As used in this description, all 
particulars regarding a specific "attachment," such as medi- 
cal specialty, acquiring modality, the patient's problem, etc., 
can be ignored. These are details having absolutely no 

5 bearing on the essence of the present invention. The only 
requirements are that the information must be something 
that can be digitized and therefore put into the form of a 
computer file, and that once in this form, it can be "read, 
reviewed or interpreted" by the person or organization 

1Q receiving it. 

In addition, it should be noted that the DCF could be 
usefully employed independent of the "attachments" prob- 
lem. The DCF is an electronic form (with specific fields that 
must be filled out) that adjusts itself, in both information 
required and formatting, to meet the demands of the receiv- 

35 ing party. Furthermore, it does this while maintaining a 
Standard User Interface. It is particularly advantageous for 
Electronic Data Interchange (EDI) situations where a user 
must send similar (but not necessarily identical) messages to 
several organizations. This is particularly important where, 

20 once an electronic form is received by those organizations, 
the information in the message must be digitally integrated 
into differing information systems. 

The exemplary preferred embodiment discussed above 
addresses only a stand-alone system of computers, which is 

25 independent of the practice management software in the 
local dentist's office, the claims management software at 
each insurance company, and of clearinghouses such as 
NEIC. However, it will be appreciated that there is an entire 
spectrum of different ways to structure a system which will 

3 q support "attachment integrated claims" which will be readily 
apparent to a person of ordinary skill in the art (after having 
the benefit of the present disclosure), all of which are 
encompassed by the present invention. 

It should also be noted that the AIC software described 
thus far has been independent of the service provider's 

35 practice management software. However, one alternative 
preferred embodiment calls for integrating the AIC software 
with the practice management software. This would further 
reduce the amount of time spent actually filling out the PAC 
application and the other paperwork involved in the overall 

40 claims process. 

Electronic filing of standard 100% text claims is now 
being supported by many practice management systems and 
by stand-alone electronic claims software systems. In 
another alternative preferred embodiment, the AIC software 

45 could be incorporated into these systems as a means of 
sending the x-ray part of the PAC application. 

It should also be mentioned that the present invention 
represents a total solution on three levels to the problem of 
streamlining the processing of insurance claim forms with 

50 attachments. First, the system from provider to third party 
payer is totally digital. The present invention includes an 
integrated system of hardware and AIC software that allows: 
(1) providers to create an electronic (digital) version of a 
patient's PAC application (text and x-ray); (2) providers to 

55 transmit the PAC application to an insurance company; and 
(3) the insurance company to read the patient's PAC appli- 
cation. Thus, it creates a coherent system for the filing, 
transmission and processing of "claims with attachments." 
Secondly, the present invention is an industry-wide sys- 

60 tem which allows every provider to interface with every 
third party payer. Finally, the present invention is a system 
which permits all communications between the service 
provider and the insurance company to be totally electronic. 
The present invention makes the entire process electronic 

65 from the initial preparation of the PAC form to the payment 
of the final claim. Communication is digital in both direc- 
tions. 
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As discussed above, the patient, the service provider, the 
insurance company, or any combination thereof may prefer 
that all communication be performed through a value-added 
service provider 500. The services performed by the value- 
added service provider 500 advantageously could include 5 
any or all of the services listed immediately below. 

First, the value-added service provider 500 may act as a 
National Dental Data Bank (NDDB), i.e., a data bank storing 
patient dental images. Limited information regarding the 
patient from the PAC form is attached to the digital x-ray to 1(J 
produce a digitized x-ray record. This information could 
include, for example, the date that the x-ray was taken, the 
identity of the service provider who took the x-ray, the 
patient's name and social security number, etc. The digitized 
x-ray record is archived at NDDB for the patient. This would 
allow the retrieval of the x-ray by the patient at any time for 15 
any reason, e.g., the patient could ask that the x-ray and 
claim be sent to another dentist for a second opinion and/or 
for a second price estimate. In fact, the patient may request 
that the PAC application be sent to other qualified service 
providers so that they could competitively bid on the needed 20 
procedure. 

In addition to the NDDB function, the value-added ser- 
vice provider 500 could perform pre-screening of the PAC 
applications for errors and could provide statistics to both 
the service providers and the insurance companies 25 
regarding, for example, the frequency at which a procedure 
is performed or the frequency at which follow up treatment 
is required after a first procedure is performed. The value- 
added service provider 500 could also do the prior approval 
review for an insurance company or could provide other 30 
services tailored to suit the needs of the service provider, the 
patient, and/or the individual insurance company. 

It should be mentioned that there are three outside areas 
of software that advantageously can be taken into 
consideration, or ignored, with the present invention. These 35 
are practice management software run by the service 
provider, claims management software run by the insurance 
company, and clearinghouse software. The present invention 
allows for the entire spectrum of interfacing, from a totally 
stand-alone system for electronic claims processing to one 40 
that is fully integrated with practice management software, 
claims management software, and the NEIC. Moreover, the 
present invention is specifically contrived so that it can be 
used simultaneously in all modes. That is, one insurance 
company could choose to have no interfacing between the 45 
computer 310 running the AIC software and its mainframe 
computer 350, while, at the same time, another insurance 
company could choose to have AIC software running simul- 
taneously on both the mainframe computer 350 and the 
buffer computer system 310. Thus, each operating mode or 50 
methodology could be considered to be a different preferred 
embodiment of the present invention, notwithstanding the 
fact that all modes are expected to be operating simulta- 
neously. 

The present invention was motivated by a desire to solve 55 
a problem which has existed for many years. The AIC 
software was designed with this in mind. Thus, for example, 
redundant information is automatically moved from one 
form and file to another along the chain of operating steps, 
i.e., from one document to another within a given insurance 60 
company's set of forms. Moreover, the AIC software advan- 
tageously can be written in C++ or some other appropriate 
programming language. The reason for this is so that when 
information in entered into areas of the electronic PAC 
forms, it is entered as a "field." Being a "field" it can be used 65 
as a logic control device, as discussed in greater detail 
above. 
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The overall workflow problem to be addressed is treated 
as a coherent whole. Thus, AIC software is specifically 
designed so that, at each step of the preferred operating 
method, the fact that the information is in digital form is 
used to streamline the process. Thus, the AIC software is 
designed to eliminate inefficiencies and deficiencies that 
exist in current claims handling systems. For example, the 
information itself can be used as a logical control device and 
it can also be transferred from one document to another. It 
should be noted that all available forms are written into the 
AIC software so that they are coordinated with one another, 
that is, they know where each has a similar "field." 

It should also be noted that the AIC software automates 
much of the overall insurance claims processing, thus elimi- 
nating many of the areas that are repetitive or prone to 
human error. These areas include the following: 

(a) Filling in the service provider's information. Although 
each insurance company may require something dif- 
ferent in the way of service provider information, the 
AIC software can store consolidated service provider 
information so that the information need be entered 
only once. For example, the service provider need only 
enter his telephone number once; the AIC software can 
reformat this basic information specifically for each 
individual insurance company's form; 

(b) Transmitting the PAC application to the correct e-mail 
address, thus eliminating the errors associated with 
hand addressing and stamping the mailing envelope; 

(c) Checking each completed form, i.e., PAC application 
and Predetermination form, for accuracy and 
completeness, while it is still at the provider's office or 
the insurance company; and 

(d) Simultaneously transmitting, archiving, and printing 
the completed forms, e.g., the PAC application. 

It will be appreciated that many such advantages will be 
evident to those of ordinary skill in the art from having the 
requisite PAC form stored in the AIC software on the service 
provider's computer system 210, 240. 

Moreover, the AIC system advantageously can be opti- 
mized to limit unnecessary information. For example, the 
system can make use of scanners 220 which have portions 
of their scanning area physically or electronically masked 
out, which reduces both scanning time and transmission 
time by minimizing the size of the digitized x-ray produced, 
for example, during step S104. The provisions for the use of 
digital and digitized signatures also eliminates unneeded 
paper shuffling. 

It should again be noted that the major improvement in 
efficiency attributable to the AIC system results from com- 
bining or coordinating an electronic PAC form with an 
electronic (digitized) x-ray. This electronic x-ray will have a 
document identification number assigned to it. 

In addition, the AIC system and corresponding method 
according to preferred embodiments of the present invention 
provide several convenience features which are only pos- 
sible when using a fully electronic fifing system. For 
example, the AIC system facilitates automatic acknowledg- 
ment by the insurance company that it has received the PAC 
application. Moreover, the AIC system provides automatic 
transfer of pertinent information from the PAC application to 
the Predetermination form. Furthermore, the AIC system 
components at the insurance company preferably allow 
simultaneous viewing of the three documents needed to 
complete the Predetermination form. In addition, the AIC 
system and requisite software automates the entire transmit- 
ting and archiving processes of the PAC application and the 
Predetermination form at the insurance company. 
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In some instances, the electronic reuse of the Predeter- 
mination form as the Final Payment Claim form means that 
the service provider need only indicate the date that the 
procedure was performed and enter the service provider's 
facsimile or electronic signature. The AIC software module 5 
at the provider's office requests these be entered into P, i.e., 
the Predetermination form, to create P*, i.e., the Final 
Payment Claim form, and then transmits P* to the final 
claims e-mail address for payment. Moreover, the only 
information that needs to be sent from the service provider 10 
to the insurance company is the insurance company's 
assigned document identification number, the date of 
completion and the service provider's signature. 

The preferred embodiments of the AIC system according 
to the present invention provide dentists in the field with the 15 
necessary hardware and software which allows them to 
create an electronic (digital) version of a patient's PAC 
application, both the text and the required patient x-ray. The 
AIC software automatically adds these two data types 
together to form a single entity, the patient's PAC applica- 20 
tion. Moreover, the AIC system provides the insurance 
companies with hardware and software which allows them 
to read the patient's electronic PAC application. For each 
insurance company, this application is tailored so that it 
contains the specific information required by that company 25 
and it contains that information in the form required by that 
company. As such, the necessity to force standard formats on 
the insurance industry is eliminated. Moreover, the AIC 
system and software automatically attaches a partially filled 
out Predetermination form to the patient's PAC application 30 
when it is called up for review and approval. Moreover, the 
AIC system and software completely eliminates the time 
consuming process of actually handling the patient's film 
x-ray by insurance company personnel. 

Other modifications to and variations of the invention will 35 
be apparent to those skilled in the art from the foregoing 
disclosure and teachings. Thus, while only certain embodi- 
ments of the invention have been specifically described 
herein, it will be apparent that numerous modifications may 
be made thereto without departing from the spirit and scope 40 
of the invention, as defined in the appended claims. 

What is claimed is: 

1. A graphical user interface (GUI) instantiated by com- 
puter software for generating a file from text data entered 
into selected ones of N fields in the GUI, wherein the 45 
selected ones of the N fields which accept text data are 
determined responsive to text entered into a first predeter- 
mined one of the N fields, and wherein N is an integer 
greater than 2. 

2. The GUI as recited in claim 1, wherein the first portion 50 
of the selected ones of the N fields are automatically filled 

in when the text is entered into the first predetermined one 
of the N fields. 

3. The GUI as recited in claim 1, wherein the selected 
ones of the N fields is further limited responsive to text entry 55 
into a second predetermined one of the N fields. 

4. The GUI as recited in claim 3, wherein the first 
predetermined one of the N fields accepts a payer name, and 
wherein the second predetermined on of the N fields accepts 

a CPT code. 60 

5. A combination of storage media storing computer 
readable instructions for permitting non-networked comput- 
ers to cooperate synergistically, comprising: 

a first storage medium storing computer readable instruc- 
tions for permitting a first computer system to generate 65 
a form including N fields, to receive textual data as field 
data in selected ones of the N fields, to assemble said 
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field data and a corresponding digitized attachment into 
a first file and to transmit the first file to a second 
computer system via a communications channel; 
a second storage medium storing computer readable 
instructions for permitting the second computer system 
to receive said first file via the communications 
channel, to display the corresponding digitized attach- 
ment on a second screen of the second computer 
system, and to transfer said field data to a third com- 
puter operatively connected to the second computer; 
and 

a third storage medium storing computer readable instruc- 
tions for permitting the third computer system to 
receive said field data from said second computer, to 
display said field data on a third screen of the third 
computer system and to generate a second file includ- 
ing portions of said field data extracted from said first 
file, 

wherein the selected ones of the N fields which accept text 
data are determined responsive to text entered into a 
first predetermined one of the N fields, and 

wherein N is an integer greater than 2. 

6. The combination as recited in claim 5, wherein the 
selected ones of the N fields is further limited responsive to 
text entry into a second predetermined one of the N fields. 

7. The combination as recited in claim 6, wherein the first 
predetermined one of the N fields accepts a payer name, and 
wherein the second predetermined on of the N fields accepts 
a CPT code. 

8. The combination as recited in claim 5, wherein said 
digitized attachment is a digitized x-ray. 

9. The combination as recited in claim 5, wherein said 
instructions in said second and said third storage media 
permit said field data, said digitized attachment and said 
second file to be simultaneously displayed. 

10. A method for operating a computer system including 
first, second and third computers, each of said first, second 
and third computers including a memory, an input device, 
and a display, respectively, said first and said second com- 
puters being connected to one another by modems and a 
common communication line, and said first computer 
including a digitizing device, said method comprising the 
steps of: 

(a) retrieving a first form including N fields from storage 
in the first computer's memory and displaying said first 
form on the first computer's display; 

(b) selecting M of the N fields responsive to text entry into 
a first predetermined one of the N fields; 

(c) writing first field data to said first form using the first 
computer's input device; 

(d) digitizing a patient's x-ray to thereby generate a 
digitized x-ray; 

(e) combining said digitized x-ray and said first form so 
as to generate an attachment integrated file; 

(f) transmitting said attachment integrated file to the 
second computer; 

(g) transmitting said first field data from said second 
computer to said third computer; 

(h) generating a second form upon receipt of said attach- 
ment integrated file, said first and second forms con- 
taining at least a portion of said first field data; 

(i) displaying said first form, said second form and an 
image corresponding to said digitized x-ray on respec- 
tive displays of said third computer and said second 
computer; 
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(j) writing second field data to said second form using said 
third computer's input device; 

(k) transmitting said first and second field data corre- 
sponding to second form back to the first computer, 

wherein M and N are both integers greater than 2. s 

11. The method as recited in claim 10, wherein the 
selected ones of the M fields is further limited responsive to 
text entry into a second predetermined one of the N fields. 

12. The method as recited in claim 11, wherein the first 
predetermined one of the N fields accepts a payer name, and 10 
wherein the second predetermined on of the N fields accepts 

a CPT code. 

13. The method as recited in claim 10, further comprising 
the steps of: 

(1) receiving said first and second field data corresponding 15 

to said second form on the first computer; 
(m) reconstructing and displaying said second form on the 

first computer's display; 
(n) adding completion data to said second form using the 2Q 

first computer's input device to thereby convent said 

second form into a third form; and 
(o) transmitting said first and second field data and said 

completion data corresponding to said third form from 

the first computer to a selected one of said second and 25 

third computers. 

14. The method as recited in claim 10, further comprising 
the steps of: 

(p) receiving said first and second field data correspond- 
ing to said second form on the first computer; 30 

(q) generating a third form responsive to receipt of said 
first and second field data corresponding to said second 
form; 

(r) automatically transferring selected portions of said first 
and second filed data to said third form; 35 

(s) entering completion data into said third form using the 
first computer's input device; and 

(t) transmitting said selected portions of said first and 
second field data and said completion data correspond- 
ing to said third form from the first computer to a 40 
selected one of said second and third computers. 

15. The method as recited in claim 10, wherein said step 
(f) comprises the steps of: 

(f)(i) transmitting said attachment integrated claim appli- 
cation to an on-line service; and 45 

(f)(ii) transmitting said attachment integrated claim appli- 
cation from said on-line service to the second com- 
puter. 

16. The method as recited in claim 10, wherein said step 

(j) comprises the steps of: 50 
(j)(i) transmitting said second form to an on-line service; 
and 

(j)(ii) transmitting said second form from said on-line 
service to the first computer. 55 

17. The method as recited in claim 10, wherein: 

said attachment integrated claim application is a Prior 

Approval Claim application; 
said digitized x-ray comprises one field of said attachment 

integrated claim application; and 6Q 
said second form is a Predetermination form. 

18. A combination of storage media which store computer 
readable instructions for permitting Mx(NxR) non- 
networked computers to form a coherent system, compris- 
ing: 65 

M first storage medium storing computer readable instruc- 
tions for permitting each of M first computer systems to 
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receive textual data as field data, to assemble said field 
data and a corresponding digitized attachment into a 
first file and to transmit the first file to a selected second 
computer system and a selected third computer system 
via at least one communications channel; 
N second storage medium storing computer readable 
instructions for permitting the selected second com- 
puter system of N second computer systems to receive 
said first file via at least one communications channel, 
and to display the corresponding digitized attachment 
on a second screen of the selected second computer 
system; and 

R third storage medium storing computer readable 
instructions for permitting the selected third computer 
system of R third computer systems to receive said field 
data of said first file via the at least one communications 
channel, and to display said field data on a third screen 
of the selected third computer system, 

wherein: 

M, N, and R are each a positive integer greater than one, 
said selected second computer system and the selected 
third computer are selected by one of the M first 
computer systems responsive to address information 
included in the field data in the first file, and 
multiple items in the field data is selected by diagnostic 
code included in the field data. 

19. The combination as recited in claim 18, wherein: 
the M first storage medium store computer readable 

instructions permit each of the M first computer sys- 
tems to receive additional textual data as additional 
field data, to assemble said additional field data and a 
corresponding digitized attachment into a second file 
and to transmit the second file to a second alternate 
computer system and a third alternative computer sys- 
tem via at lease one communications channel; 
the N second storage medium store computer readable 
instructions which permit the second alternative com- 
puter system of N second computer systems to receive 
said second file via the first communications channel, 
and to display the corresponding digitized attachment 
on a fourth screen of the second alternative computer 
system; and 

the R third storage medium stores computer readable 
instructions which permit the third alternative com- 
puter system of R third computer systems to receive 
said additional field data of second file via said the at 
least one communications channel, and to display said 
additional field data on a fifth screen of the third 
alternative computer system; and 

the selected second and third computer systems and the 
second and third alternate computer systems are des- 
ignated when the field data and the additional field data 
are entered in the dynamic claim form, respectively. 

20. The combination as recited in claim 18, wherein the 
communication channel further comprises: 

a first communications channel operatively coupling the 
first and second computer systems; and 

a second communication channel operatively coupling the 
first and third computer systems. 

21. The combination as recited in claim 18, wherein said 
communications channel further comprises a first commu- 
nications channel, a clearing house server, and a second 
communications channel, arranged in the recited order, 
operatively coupling the first computer system to the second 
and third computer systems. 
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22. The combination as recited in claim 21, wherein the 
communications channel further comprises a third commu- 
nications channel operatively coupling the second and third 
computer systems. 

23. A graphical user interface (GUI) instantiated by com- 5 
puter software for generating a file transmittable to a 
selected one of M recipients from text data entered into 
selected ones of N fields in the GUI, wherein: 

the selected ones of the N fields which accept text data are 
determined responsive to text entered into a first pre- 10 
determined one of the N fields, 

the computer software is updated as the respective file 
requirements of the M recipients change, and 

N is an integer greater than 2. ^ 

24. The GUI as recited in claim 23, wherein the first 
portion of the selected ones of the N fields are automatically 
filled in when the text is entered into the first predetermined 
one of the N fields. 

25. The GUI as recited in claim 23, wherein the selected 

20 

ones of the N fields is further limited responsive to text entry 
into a second predetermined one of the N fields. 

26. The GUI as recited in claim 25, wherein the first 
predetermined one of the N fields accepts a payer name, and 
wherein the second predetermined on of the N fields accepts 
a CPT code. 

27. The GUI as recited in claim 26, wherein the computer 
software is automatically updated whenever the file is trans- 
mitted to the one of the M recipients corresponding to the 
payer name. 3Q 

28. The GUI as recited in claim 23, wherein the computer 
software is automatically updated from a single source 
accessible by all of the M recipients. 

29. The GUI as recited in claim 23, wherein the computer 
software resides on a server computer accessible via the 35 
Internet. 

30. The GUI as recited in claim 29, wherein the file is 
transmitted from the server to the selected one of the M 
recipients. 

31. A graphical user interface (GUI) instantiated by com- 4Q 
puter software for generating a file transmittable to a 
selected one of M recipients from text data entered into 
selected ones of N fields in the GUI, wherein: 

the selected ones of the N fields which accept text data are 

determined responsive to text entered into a first pre- 45 

determined one of the N fields, 
the format of the file is determined responsive to text 

entered in the first predetermined one of the N fields, 

and 

N is an integer greater than 2. 50 

32. The GUI as recited in claim 31, wherein the first 
portion of the selected ones of the N fields are automatically 
filled in when the text is entered into the first predetermined 
one of the N fields. 

33. The GUI as recited in claim 31, wherein the selected 55 
ones of the N fields is further limited responsive to text entry 
into a second predetermined one of the N fields. 

34. The GUI as recited in claim 33, wherein the first 
predetermined one of the N fields accepts a payer name, and 
wherein the second predetermined on of the N fields accepts 60 
a CPT code. 

35. The GUI as recited in claim 31, wherein the computer 
software resides on a server computer accessible via the 
Internet. 

36. The GUI as recited in claim 29, wherein the file is 65 
transmitted from the server to the selected one of the M 
recipients. 
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37. A coherent computer system providing interoperabil- 
ity between a plurality of independent computers, compris- 
ing: 

a plurality of first computers, each of the first computers 
comprising a first storage medium storing computer 
readable instructions for permitting the respective first 
computer to: 

generate a form including N fields; 
receive textual data as field data in selected ones of the 
N fields; 

assemble said field data into a first file; and 
transmit the first file to a selected one of a plurality of 

second computers via a communications channel; 

and 

the second computers, each of the second computers 
comprising a second storage medium storing computer 
readable instructions for permitting the respective sec- 
ond computer to: 

receive said first file via the communications channel, 
and 

display said field data on a screen of the respective 

second computer, 
wherein: 

the selected ones of the N fields which accept text data are 
determined responsive to text entered into a first pre- 
determined one of the N fields, 

the selected one of the respective second computers is 
selected responsive to the text entered into the first 
predetermined one of the N fields, 

the computer readable instructions stored on the first 
computers are updated responsive to changes to the 
selected ones of the N fields generated by a respective 
one of the second computers, and 

N is an integer greater than 2. 

38. The coherent computer system as recited in claim 37, 
wherein the selected ones of the N fields is further limited 
responsive to text entry into a second predetermined one of 
the N fields. 

39. The coherent computer system as recited in claim 38, 
wherein the first predetermined one of the N fields accepts 
a payer name, and wherein the second predetermined on of 
the N fields accepts a CPT code. 

40. An electronic claim form instantiated by a Graphical 
User Interface (GUI) which permits each of a plurality of 
first users to complete and then electronically transmit N 
forms to N respective second users, wherein each of the N 
forms differs from the remaining N forms in terms of one of 
content and format. 

41. A dynamic electronic form which permits each of a 
plurality of first users to independently determine the infor- 
mation content of its respective electronic form, and to 
freely change the information over time, 

42. The dynamic electronic form as recited in claim 41, 
wherein the electronic form presented to each of a plurality 
of second users is constant, irrespective of changes to the 
information content dictated by a respective one of the first 
users. 

43. Adynamic electronic form accessible via a computer 
which provides a first user with the ability to freely select a 
second user from a plurality of second users, and which 
assists the first user in determining, assembling, and trans- 
mitting information specifically required by the second user, 
wherein the dynamic electronic form maintains a constant 
appearance irrespective of changes to required information 
established by any of the second users. 

***** 
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FIG. 3 

WORKFLOW OVERVIEW 
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FIG. 5 

PROGRAM FLOW: WORKFLOW BLOCK 
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FIG. 9 

PROGRAM FLOW: MTIALIZESTEP BLOCK (i ThisStep, i-9 ProcessList) 
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WORKFLOW MANAGEMENT SYSTEM FOR 
AN AUTOMATED CREDIT APPLICATION 
SYSTEM 

s 

BACKGROUND OF THE INVENTION 

1. Field of the Invention 

The present invention relates generally to an Automated 
Credit Application System and more particularly to a work- ^ 
flow management system for an Automated Credit Applica- 
tion System. 

2, Related Art 

Processing loan and credit applications is a complicated 
process involving numerous tasks that must be completed in 15 
a particular order by banks and other lending institutions. 
Such tasks include filling out a loan application, verifying 
financial and employment information, checking credit 
reports from one or more credit bureaus, verifying collateral, 
making the loan decision and administrating the loan. 20 

These tasks are generally performed by multiple groups 
within a lending organization. For example, loan officers 
typically work with applicants to complete the credit appli- 
cation. An underwriter or underwriter group decides whether 
to issue or "book" the loan based on information from the 25 
credit application, current business guidelines, and informa- 
tion from outside agencies, such as credit bureaus and the 
like. An administrative group distributes payment coupons, 
receives loan payments and handles other administrative 
tasks during the life of the loan. 30 

Generally, each task involves many steps which are 
conventionally performed manually by various people and 
organizations within the lending institution. The necessary 
participation between various work groups makes it difficult 
to manage the complicated process of preparing credit 35 
applications in an efficient manner. 

Recently, a new tool has become available to financial 
institutions that alleviates many of the problems brought 
about using conventional manual loan processing tech- 
niques. These automated credit application systems auto- 40 
mate many of the tasks that have conventionally been 
performed manually. 

One such example of an automated credit application 
system is CreditRevue® by CMSI of Columbia Maryland. 45 
CreditRevue automates the loan application process from 
the inception of the loan application to loan administration. 
All data is gathered and handled electronically throughout 
the entire lending process according to unique requirements 
of each lending institution. 5Q 

For example, CreditRevue provides loan officers with an 
on-line credit application that is customized for each lending 
institution according to their specific requirements. Once a 
credit application has been entered into the automated 
system, CreditRevue typically communicates with one or 5S 
more credit bureaus to retrieve credit reports on behalf of the 
loan applicant. 

CreditRevue can then make a credit decision based on 
scoring rules and other criteria as required by the lending 
institution. For example, automated credit decisions can be $q 
generated using a combination of advanced credit bureau 
analysis, multiple scoring models and judgmental review. 
The automated system can also monitor lending policy 
guidelines to ensure compliance from both a regulatory and 
managerial standpoint. 65 

In addition, CreditRevue can assist in loan administration 
and prepare loans for booking by verifying documents and 
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contract details. The system can also automate the transfer of 
a booked application to the lending institution's servicing 
system. 

As stated, each lending institution generally has unique 
requirements for processing loans. For example, decision 
making rules are generally different among lending institu- 
tions. Workgroups and workgroup responsibilities are 
unique for each lending institution. Steps used to process 
loan applications and the order in which these steps are 
processed vary widely among lending institutions. Many of 
these parameters are also subject to change within single 
lending institution. 

Because of the unique and dynamic nature of loan pro- 
cessing requirements, it is very difficult to provide an 
automated credit application system that will satisfy the 
needs of multiple lending institutions. Accordingly, provid- 
ers of such systems must customize their software in order 
to comply with the unique requirements of their clients. 
Customization typically involves changing and adding 
source code modules to the base automated credit applica- 
tion system, This causes a significant increase in cycle time 
for development and testing. Clearly this customization is 
extremely costly for both the system providers, the lending 
institutions and ultimately, the consumer. 

Workflow management is one area of automation that is 
subject to much customization. In general, workflow man- 
agement defines and manages the credit processing steps 
that are needed to complete a credit application. This 
includes identifying individuals and/or workgroups that are 
responsible for completing each step in the credit application 
process. 

Generally, workflow requirements vary widely among 
lending institutions. For example, one organization may 
require that an underwriting group or individual make final 
loan decisions based on information reported by the auto- 
mated system. Another organization may desire to allow the 
automated system to approve loans based on automated 
analysis of predetermined criteria. 

In another example, it may be desired to automate the loan 
approval process but also allow certain exceptions to be 
made by authorized workgroups or individuals. In this 
example, certain items that would otherwise cause a loan to 
be rejected can be waived by one or more authorized 
individuals or work groups. 

As stated, providers of automated credit application sys- 
tems customize their software according to the unique 
workflow requirements of each lending institution. 
Conventionally, workflow management is hard-coded 
according to the needs of each lending institution. For 
example, CreditReveu uses named stations to implement the 
workflow management system. Each named station is asso- 
ciated with one or more physical workstations that are 
connected to the automated credit application system. As the 
workflow progresses, outstanding process steps are pro- 
cessed only at the named stations associated with the par- 
ticular process step- 
Using this conventional method, users are forced to go to 
one of these named stations to access the credit application 
and to perform functions thereon to complete the credit 
application. In this fashion, credit applications are trans- 
ferred from one named station to the next, depending on 
which steps are to be completed next. 

For example, during application entry, the credit applica- 
tion is only accessible at the workstations associated with 
one or more loan officers. Similarly, during the underwriting 
stage, the credit application is only accessible at the work- 
stations in the underwriting group. 
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Generally, in order to move the application along, users 
are forced to manually complete the outstanding steps at the 
associated named station. Once the step or steps are 
complete, users manually transfer the application to the next 
named station according to the customized preprogrammed 5 
workflow. Using the conventional method, the workflow is 
isolated in this fashion, and the processing of credit appli- 
cations is performed in a serial manner that cannot be altered 
without having to re-customize the automated credit appli- 
cation system's source code. 3 q 

Therefore what is needed is a workflow management 
system that provides additional flexibility so that the work- 
flow is not restricted to serial processing using prepro- 
grammed named stations. In addition what is needed is a 
workflow management system that can be customized 15 
according to requirements of lending institutions without 
having to customize the source code each time the workflow 
requirements change. 

SUMMARY OF THE INVENTION 

20 

Accordingly, the present invention is directed toward a 
workflow management system for an automated credit appli- 
cation system that is flexible and can be easily customized 
according to individual requirements of financial institu- 
tions. The steps and rule tests that define an organization's 25 
workflow are customized according to workflow require- 
ments and process steps for each organization. This is 
accomplished using the present invention without having to 
develop and change the source code associated with the 
automated credit application system. In particular, a work- 30 
flow configuration tool is used at run-time to define custom- 
ized workflow requirements. This alleviates that need to 
customize source code for each client and each time work- 
flow requirements change. 

The workflow management system of the present inven- 35 
tion automatically manages the workflow and allows for 
application steps to be processed in a parallel fashion, rather 
than the serial method found in conventional systems. Work- 
groups are defined for each pre-configured workflow defi- 
nition of the present invention. Each workgroup is associ- 40 
ated with a particular seL of functions that the workgroup has 
responsibility for. In addition, each workgroup has a work- 
group queue associated with it. Workgroup queues contain 
all of the active steps associated with the workgroup. Active 
steps are workflow process steps that are currently pending 45 
and ready to be processed. Each workflow queue is auto- 
matically updated as soon as prerequisite steps are com- 
pleted according to the customized workflow model. 

In this fashion, users in a particular workgroup can for 
example, view all of the applications which have active steps 50 
pending for the workgroup. In another example a user can 
ask to see all of the pending applications in which a 
particular step needs to be completed. In addition, users can 
instantly view progress data related to credit applications 
being processed. For example, users can determine exactly 55 
what stage a credit application is in, and which workgroup 
or individuals have the responsibility to act next. Still 
further, users can determine precisely what conditions may 
be present that are preventing credit applications form 
progressing to completion. 60 

The workflow management system of the present inven- 
tion automatically coordinates the workflow among various 
workgroups and entities involved in the credit application 
process. The workflow management system of the present 
invention automatically controls and manages which pro- 65 
cess steps can be worked on by various workgroups simul- 
taneously. 
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A relational database management system is used to link 
a plurality of rule tests with each workflow process step that 
is defined for particular workflow. Rule elements are linked 
to tests that are linked to database elements which are linked 
to functions that alter the database elements. Accordingly, 
when a function is executed, the workflow management 
system of the present invention automatically determines 
which particular workflow process steps are potentially 
affected by the executed function. Then, the workflow 
management system of the present invention evaluates those 
steps to determine their status (i.e. complete, incomplete, 
etc.), and determines which process steps are next activated. 

BRIEF DESCRIPTION OF THE FIGURES 

The present invention is described with reference to the 
accompanying drawings, wherein: 

FIG. 1 is a block diagram depicting an operational envi- 
ronment according to a preferred embodiment of the present 
invention; 

FIG. 2 is a block diagram depicting components of the 
workflow management module according to a preferred 
embodiment of the present invention; 

FIG. 3 depicts a functional overview of the workflow 
management system that is useful for describing the inter- 
relationships between workflow management elements 
according to a preferred embodiment of the present inven- 
tion; 

FIG. 4 depicts a block diagram of a workflow definition 
and a workflow configuration tool according to a preferred 
embodiment of the present invention; 

FIGS. 5-9 are flowcharts depicting methods that can be 
used to implement the workflow management system 
according to a preferred embodiment of the present inven- 
tion; and 

FIG. 10 is a block diagram of a computer useful for 
implementing components of the present invention. 

DETAILED DESCRIPTION OF THE 
PREFERRED EMBODIMENTS 

FIG. 1 is a block diagram depicting an operational envi- 
ronment according to a preferred embodiment of the present 
invention. A computer system running an automated credit 
application system is shown as block 102. The computer 
system 102 is coupled with a local area network (LAN) 108. 
The LAN 108 is shown as an example only, and any type of 
computer network can be used. This includes multiple LANs 
coupled together with routers, leased telephone lines and/or 
public or private switched telephone networks to form wide 
area networks (WANs) and the like. The use of multiple 
private and public computer networks, such as the Internet, 
can also be used in alternate embodiments of the present 
invention. Typically however, the automated credit applica- 
tion system is coupled with one or more LANs, such as the 
LAN 108, that is typically confined for security purposes, to 
a geographical location associated with a lending institution. 
This does not prohibit remote access to the LAN 108, which 
may also be implemented in various embodiments of the 
present invention. 

A plurality of workstations, Wl, W2, . . . WN 106 is 
coupled with the LAN 108. Generally, these workstations 
are directly or remotely attached to the LAN 108, and are 
used to interact with the automated credit application system 
102. A database management system (DBMS) 104 is 
coupled with the LAN 108. The DBMS 104 is used to store 
data associated with the automated credit application system 
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102. Preferably, a relational DBMS, such as Progress® 
DBMS provided by Progress Software Corporation of Bed- 
ford Massachusetts is used. 

A preferred embodiment of the present is implemented 
using Progress® 4GL, provided by Progress Software Cor- 
poration of Bedford Mass. Progress 4GL is a high-level 
Forth-Generation development language used to create 
applications using object-oriented, event-driven and struc- 
tured programming techniques. The use of Progress 4GLis 
an example of the preferred method of implementing the 
automated credit application system of the present inven- 
tion. Other programming methods and tools can be used to 
implement alternate embodiments. Such alternate embodi- 
ments will be apparent to persons skilled in the relevant 
art(s), and are therefore within the purview of the claims 
listed below, which define the scope and breadth of the 
present invention. 

A network device 110 is attached to the LAN 108 in the 
example operational environment shown in FIG. 1. The 
network device 110 is used to connect the automated credit 
application system 102 with remote computers, such as the 
remote credit bureau computers, as depicted by the block 
114. 

FIG. 2 is a block diagram depicting components of the 
workflow management module according to a preferred 
embodiment of the present invention. Block 202 represents 
users that interact with the workflow management compo- 
nent 200 via a user interface or Screen module 204 to 
perform Functions 206, such as to interact with their work- 
flow queue screen. For example, the application workflow 
queue screen is stored in the Screen module 204. 

Functions 206 can affect data elements 214 stored in the 
database 104. Examples of functions stored in the function 
module 206 include the NOTICE and SYNC functions, 
which are subsequently described below with references to 
FIGS. 6 and 7, respectively. A Rule module 208 stores tests 
and derives values for predetermined rule objects based on 
stored data elements in the database 104. An example of a 
test stored in the Rules module 208, is a test to determine 
whether a particular workflow step is complete. 

Functions 206 allow users to perform actions. Functions 
206 can be securable. That is, each function in the Function 
module 206 can be associated with a particular level of 
security so that only authorized personnel having that level 
of security or above can perform the specified function. 

Functions 206 can read and/or write data elements 214 to 
the database 104, and can affect rule objects in the Rules 
module 208. Preferably, Functions 206 maintain a list of rule 
objects that they manipulate. Whenever a user 202 performs 
a Function 206 that changes one or more data elements 214 
in the database 104, at least one rule object in the Rules 
module 208 is typically modified. In this fashion, an auto- 
matic notification feature is provided to the workflow man- 
agement module 200 so that it can dynamically and effi- 
ciently determine the status of workflow process steps 
(described below). 

For example, the automatic notification feature of the 
present invention allows the workflow management module 
200 to dynamically and efficiently determine which work- 
flow process steps are completed, and which steps are to be 
performed next, in response to functions performed by users. 
Workflow process steps and their associated attributes are 
stored in the Internal Data module 212. This feature of the 
present invention is described in detail below. 

The Code Library module 210 is used to store library 
routines for the Screen module 204 and the Functions 
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module 206. Example of routines stored in the Code Library 
module 210 include common actions performed on screens, 
such as a browser function, and maintenance functions 
providing security for access requests, audit trails and the 

5 like. Other modules of the automated credit application 
system of the present invention that can access the workflow 
module 200 are represented by block 216. 

FIG. 3 depicts a functional overview of the workflow 
management system that is useful for describing the inter- 

10 relationships between workflow management elements 
according to a preferred embodiment of the present inven- 
tion. Block 302 represents functions 206 performed by users 
that cause a change to one or more database elements 214 in 
the database 104. As depicted by block 304, a database 

1 5 element is altered as a result of a database save action from 
a user. Each function has an associated set of rule elements 
208, as depicted by the block 306. More specifically, each 
database element 214 has one or more rule elements 208 
associated with it. A rule element is used to derive infor- 

20 mation from one or more database elements 214. An 
example of a rule element is * Total Income*. Total Income 
can be a summation of several database elements, including 
for example, primary income' , 'secondary income' and 
'alternate income'. 

25 Each rule element 306 may be associated with one or 
more tests 308. Tests are preferably of the BOOLEAN type 
and are either TRUE or FALSE. An example of a test 308 
associated with the Total Income rule element is: 'If Total 
Income is Greater than $20,000, then the test object is 

30 TRUE/ The test object is used for example, to determine if 
a particular processing step is complete, or can be skipped. 

Credit Application process steps are represented by block 
310. Steps 310 are tasks that users perform in the lending 

35 process that require completion in order to complete the 
credit application. Steps may be manually performed by 
users or automatically performed by the credit application 
system of the present invention. Each step 310 has a specific 
set of rules 306 associated with it. More specifically, each 

40 step 310 is associated with a specific set of tests 308 which 
arc each associated with a specific set of rule elements 306. 
As stated, each rule element 306 is associated with a 
database element 304, which is associated with a function 
302. 

45 In this fashion, because the association between process 
steps 310, tests 308, rule elements 306, database elements 
304 and functions 302, the workflow management system of 
the present invention can determine what process steps 310 
may be affected whenever a user (or the automated credit 

50 application system), performs a specified function 302. This 
may or may not cause an update to a user or group workflow 
queue 312 (described below). This feature is referred to 
herein as an automatic notification feature and is represented 
by the dotted line 314 between the function block 302 and 

55 the steps block 310. 

The associations between workflow management ele- 
ments 310308,306, 304 and 302 are preferably imple- 
mented with the use of a relational database management 
system, such as the relational DBMS 104. Specific methods 

60 using database tables, indexes and database management 
tools, to relate these elements according to the descriptions 
provided herein, would be apparent to persons skilled in the 
relevant art(s) and are therefore not described in detail 
herein. 

65 An example is presented below to further describe the 
automatic notification feature 314 of the present invention. 
In this example, a user performs a function 302 to modify 
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employment information. For example, a loan officer inputs associated with the workflow process steps. The workflow 

an applicant's income into the credit application an saves the configuration tool can be used by the end user (i.e. financial 

information. institution), the provider of the automated credit application 

When the ban officer saves the information, several system, or both, depending on the specific implementation 

database elements 304 are updated. For the purposes of this 5 of the present invention. In general the workflow configu- 

example, it is assumed that two database elements are ration tool is used to create process steps 310 and associated 

updated, namely: 'primary income' and 'secondary income.' tests 308. Pre-created process steps are then selected to 

In this example, it is assumed that the associated rule define a workflow for a particular financial institution, 

element 306 'total income*, is derived from the database FIG. 4 depicts a block diagram of a workflow definition 

elements of primary and secondary income. In this example 10 and a workflow configuration tool according to a preferred 

the rule element 306 is derived as follows: 'Total Income^ embodiment of the present invention. A workflow configu- 

primary income+secondary income. ' ration tool is depicted by the block 402. In a preferred 

Next, assume that a test 308 associated with the total embodiment, the workflow configuration tool 402 allows 

income rule element was created. This test is referred to users t0 define and select workflow process steps to build a 

herein as "Verify" test. In this example, the Verify test is 15 workflow definition 404. The workflow definition 404 is 

TRUE if the total income is greater than $20,000. Next, comprised of a plurality of workflow process steps. In this 

assume that a process step 310 exists that requires the example, the process steps are depicted as the horizontal 

applicant's income to be verified, only if the Verify test is lines 418a, 4186 . . . 418a» (generally 418). The workflow 

TRUE. If the Verify test is FALSE, the process step is process 418 steps in this example are divided in sections, 

skipped. 20 406,408 and 410, that represent application entry, under- 

Therefore, using the above example, the user action of writing and loan administration, respectively, 

inputting and saving the applicant's income to the database, In a preferred embodiment, three types of steps 418 can 

causes the Verify test to be evaluated. If the test is TRUE, the be defined for a workflow 404 as indicated by block 414. 

process step becomes an active step in the workflow. If the The types of steps are normal steps, exception steps, and 

test is FALSE, the process step is skipped. Accordingly, the 25 automatic steps. Steps can also be categorized as manual 

appropriate workgroup queue(s) 312 are updated to include steps, in which case, user action is required to complete the 

the process step only if the Verify test is TRUE. step, in addition to any associated tests. Generally, a user 

Each workgroup defined in a workflow has an associated completes a checklist to indicate that a manual step is 

workflow queue 312. The workflow queue lists each of the 3Q complete. Normal steps are individual action items that must 

applications that have process steps which are currently occur to a credit application before it is considered complete, 

active and may be performed by a member of the associated Exception steps are used to manage any exceptions encoun- 

workgroup. Process steps are considered active whenever tered in the normal processing of credit applications. Excep- 

their associated prerequisite steps have been completed. uon ste P s are typically configured to follow the actual step 

Generally, users can view the workgroup queue according to 35 mat causes the exception. Automatic steps are steps that 

customized constraints, such as viewing particular applica- cause me automated credit application system to automati- 

tions that need attention or particular workflow process cally run a function when the step becomes the next step in 

steps. an application's workflow. 

It is important to note that the automatic notification The automated credit application system of the present 

feature 314 of the present invention provides for an efficient 40 invention preferably maintains a library 210 of all unique 

method to evaluate process steps. In this fashion, only processing steps in any workflow. To add a new step to a 

process steps that may be affected by a particular function is predefined workflow, the configuration tool 402 can select 

evaluated in response to the function. This alleviates the an existing step from this library 210, or can create a new 

need for the automated credit application system of the normal, automatic or exception step. When a new step 418 

present invention to re -evaluate every process step in the 45 is created for a specific workflow 404, it is also added to the 

workflow every time a function 302 is performed. library 210, so that it can be used in other workflow 

In addition, steps that have previously been completed are definitions, 
automatically re-evaluated whenever a function is per- Preferably, steps 418 are defined in a particular order that 
formed that may affect that step. For example, a user may represents the workflow of the application. Although pro- 
update information that was previously entered into the 50 cessing steps in their specified order is not always required, 
credit application. In this instance, it may be required to the workflow 404 is built by adding steps 418 in their 
perform process steps that may have already been performed specified order. The workflow configuration tool 402 defines 
based on updated information, thus ensuring consistency of the order in which steps occur. Sometimes steps 418 can 
workflow throughout the application's life cycle. occur in any order. For example, the order in which the 

As stated, process steps 310 are steps that require comple- 55 'Verify Employment' and the 'Verify Residence' steps occur 

tion in order to complete the processing of a credit appli- would be immaterial. One can precede the other and vice- 

cation. Process steps 310 may be manually completed by versa. However, there may be instances where a specific step 

users or automatically completed by the automated credit cannot occur until the completion of another step. For 

application system. In addition, process steps may require example, a step involving loan administration 410 cannot 

custom routines to be executed in order to determine 60 occur until an underwriting step 408 is completed in which 

whether they are complete. the final credit decision is made. 

Preferably, the definition of process steps 310, including An indicator 420 referred to herein as the 'follows step' 

the order in which they are performed, are specified by a user indicator is associated with each step 418 to ensure that a 

(or initially by the provider of the automated credit appli- step is added to the workflow 404, only after a predecessor 

cation system), with the use of a workflow configuration 65 step has been completed. This prevents erroneous analysis of 

tool. The workflow configuration tool is also used to define steps that are not ready to be processed. In the above 

workflow rule elements 306 and the workflow tests that are example, the follows step indicator for the loan administra- 
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tion step is the final credit decision step. When a workflow 
404 is built for an application, steps 418 are added to the 
workflow 404 according to the follows step indicator. 

Steps 418 may be grouped together to form a block of 
steps. When this is done, the grouping step is referred to 
herein as the 'parent' and each individual step of the group 
is referred to as the ' child* . Child steps can also group 
additional steps, and in doing so, become parents steps 
themselves. 

Accordingly, each step may have a parent and children. A 
step may also be standalone with no parent or children. 
Preferably, parents and children are created by indenting 
child steps from their parent step as presented by the 
workflow configuration tool 402. A child step has an indi- 
cator 420 which identifies the parent step. This parent child 
relationship is depicted in FIG. 4 as indented horizontal lines 
that represent steps 418. For example, because 4182> is 
shown as being indented from step 418a, step 4186 is a child 
of step 418a. 

In addition, steps 418 can be tagged with a 'collateral- 
specific' indicator as shown by block 420. This tag indicates 
that the processing step must be completed separately for 
each applicable collateral defined in the credit application. 

As stated the workflow management system of the present 
invention uses workflow tests 308 to determine the status of 
steps have been completed. Preferably status definitions for 
workflow steps are shown in block 416 as incomplete, 
non-applicable, complete and waived. A status of complete 
is associated with steps that have been completed. Steps not 
completed have a status of incomplete. Steps that are waived 
are tagged with a waived status flag. Steps that are skipped 
are tagged with a N/A status flag. 

Each workflow step 418 may be associated with one or 
more tests, as shown by block 412. The workflow manage- 
ment system of the present invention uses tests 412 to build 
a workflow for an application and to define how a step 418 
is processed. The step type 414 determines which tests 412 
are needed to ensure the correct processing of the step. It 
should be recalled that in general, tests use rules which link 
activity with workflow steps so that when a function is 
performed, the workflow management system knows which 
steps may have been affected. Those steps are then evaluated 
using the associated tests to determine the status 416 of the 
potentially affected steps 418. 

When a user configures a workflow 404, tests 412 are 
added to each step being defined. Thus, each step 418 has a 
one or more sets of associated tests 412. As tests are added 
to steps, the functions that update the values used in the tests 
are tracked so that when the function is accessed the 
workflow management system knows which steps require 
analysis. 

Preferably, three types of tests can be defined for work- 
flow steps 418. These types are shown as blocks 422 and 
423. As shown, Skip and completion tests 422, preferably 55 
apply to step types 414 of normal. Exception tests 423 
generally apply to exception step types 414. Skip tests are 
used to determine the presence of a specified criteria that 
would cause the associated step 418 to be tagged with a 
status of N/A as shown by status block 416, Steps 418 60 
having a status 416 of N/A do not apply to the workflow, and 
are therefore skipped. For example, one step may be to send 
out a decline letter to the applicant. However, this step 
should be skipped if the applicant is granted a loan. 

A completion test or test set 422 is tested to determine if 65 
the associated step is complete. When steps are complete, 
the next step which has follows step indicator 420 pointing 
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to the completed step, can become active (i.e. ready to be 
performed). It should be recalled that active steps appear on 
at least one workflow queue 312. For example, on the 'Enter 
Contract Information' step, the completion test may be 
'Contract date is available/ Accordingly, when the test is 
evaluated and the workflow management system determines 
that a contract date is available, the step is marked complete 
and subsequent steps become active in the workflow. 

The following is a list of some of the unique terms used 
to describe the present invention. 



Processing An individual action item that must occur to a credit 
Step (or step) application during its life cycle. 

Function Action or set of actions performed by a user or performed 

automatically by the present invention that causes data to 

be written to the database. 
Tests Set of instructions that tests or compares values on an 

application with other values or a predefined parameter 

and returns either TRUE or FALSE. 
Completion Tests that are tested to determine if a step is complete. 
Tests 

Exception Tests that are only applicable for exception steps and act 
Tests as both skip and completion tests for exception steps. 

Skip Tests Tests that are tested to determine if there is a special 

circumstance that would cause the step to not apply to the 

workflow and therefore be skipped. 
Which to Use Tests that determine which set of skip and completion 
Tests tests to use. 

(Sublines) 

Automatic Special type of step that causes the workflow 
Step management system to automatically run a function 

when the step becomes the next step in the 
application's workflow. 
Exception Special type of step used to manage any exceptions 
Step encountered in the normal processing of applications. 

Manual Step Step on which, regardless of the presence of completion 

rules, the user must indicate that the step is complete. 
Next Step Step to be completed next in an application's workflow. 

While several steps may be outstanding at any given 
time, only one step is the next step for any given 
workgroup. 

Workgroups Defined groups that contain one or more users, used to 
visualize applications to the people who work on them. 
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FIGS. 5-9 are flowcharts depicting methods that can be 
used to implement the workflow management system 
according to a preferred embodiment of the present inven- 
tion. The WORKFLOW method 500 is depicted in FIG. 5. 
The method begins with step 502, where control immedi- 
ately passes to step 504. In step 504 a function 302 is 
executed which causes a write to the database 102 (also see 
block 304). In step 506, the WORKFLOW method 500 
determines whether the executed function 302 is a 'Notice- 
able' function. Noticeable functions are functions that are 
associated with the evaluation of a credit application and 
write to the database 104. This is in contrast to other 
functions that may be performed, such as maintenance 
functions and the like, which are not relevant to the work- 
flow management system. A function is identified as being 
Noticeable through the use of a flag (or equivalent) stored in 
the database table row associated with the function. 

As indicated by step 506, if the executed function is not 
Noticeable, control passes back to step 504, where 
essentially, the method 500 waits until another function is 
executed, and step 506 is repeated. If step 506 determines 
that the function from step 504 is Noticeable, control passes 
to step 508. 

In step 508, another method referred to herein as 
'NOTICE' is called. The NOTICE method 508 is used to 
update a list comprising active process steps 310 that need 
to be evaluated as a result of Noticeable executed functions. 
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Active process steps refer to steps that are ready to be If a parent process step does exist, control passes to step 

executed. Active process steps are steps that appear on at 612. Instep 612, the method determines if the parent process 

least one workflow queue 312. Evaluating a process step step is already included in the processList. If it is, then the 

involves determining whether the status of a process step has NOTICE method 508 ends as indicated by step 634. If the 

changed because of the executed function. Tests 308 asso- 5 parent process step is not already present in the processList, 

dated with a process step are used to make this determina- thca it is added l0 tne proccss List in step 618, and the 

tion. For example, a completion test set is used to determine method ends with step 632. 

if a process step has been completed. A skip test set is used _ A t „ *<\a •» • J4 • ^ 

to determine if a process step is non-applicable (N/A) or is Co f 0 } to ste P *™> lf in s ^ m * * ^nnined 

to be skipped. A exception test set is used to determine if an in that the function is not of the type Status Update . In step 

exception should be made. 10 610 > the method determines if the function is of the type 

Ibc NOTICE method 508 (described in detail below), 'Activate Step'. This indicates that a process step (referred 

essentially adds process steps to an internal list maintained t0 ThatProcess), has just been activated. If so, control 

by the workflow management system referred to herein as P**** t0 ste P 612 > where the method adds * e P rocess ste P 

the 'processList' . Accordingly, the internal processList com- to ih * processList, if it isn't already present, as indicated by 

prises a list of active process steps that need to be evaluated 15 ste P s 612 and 618 ^ ensures that as ste P s m added 

by the workflow management system of the present inven- dunn S the lifecycle of the application, they are always 

tion. It should be noted that the processList is an ordered list evaluated at least one time. The NOTICE method 508 then 

according to the hierarchy of the process steps. In this cnds w * tn ste P ^2. 

fashion, child steps are automatically evaluated before par- Control passes to step 614, if the tests from steps 604 and 

ent steps. This avoids the scenario of evaluating a parent step 20 610 are both negative. In step 614, the method determines if 

before a child step, and then having to immediately the function is of the type that changes a SubLine of a 

re-evaluate the parent step a second time, because the child process step, A SubLine is a classification used to identify a 

step was just evaluated particular set of completion tests, skip tests or exception 

After the NOTICE method 508 is executed, control passes tests ( 422 a ° d 423 ) associated with a process step. It may be 

to step 510. In step 510, the WORKFLOW method 500 desirable at times, to change one or more of these set of tests 

determines if any additional functions have been executed. for a particular step. In this fashion, the same process steps 

This can be true for example, if one or more additional can be used in different workflows, each having different 

functions have been executed while the workflow manage- sets of rules or SubLines. Thus, a change SubLine function 

ment system was processing step 508. If so, control passes 3Q is provided for this purpose. 

back to step 504, and steps 504-510 are repeated until no As step 614 indicates, if a change SubLine function has 

additional functions are pending. been executed for a process step, the child process steps are 

Next control passes to step 512, In step 512, another added to the processList (if not already present), as indicated 

method referred to herein as the SYNC method is called. The by step 620. The NOTICE method 508 then ends as indi- 

SYNC method 512 essentially removes process steps from 35 cated by 632, 

the processList, after being evaluated. The SYNC method Control passes to step 622, if the executed function is not 

512 is described in detail below. Next, as step 514 indicates, of the three types tested in steps 604, 610 and 614. This 

the WORKFLOW method 500 ends. The WORKFLOW represents usual processing for most functions that affect the 

method 500 will be repeated whenever another function is status of a credit application. This is to be contrasted with the 

executed. 40 three previously mentioned special types of administrative 

An example of a method that can be used to implement internal functions originating essentially from the SYNC 

the NOTICE method 508 will now be described with method 512. 

reference to FIG. 6. The NOTICE method 508 begins with In step 622, the NOTICE method 508 finds process steps 

step 602, where control immediately passes to step 604. In that may be affected by the function that was just executed, 

step 604, the method 508 determines if the noticeable 45 Preferably, this is accomplished by searching function lists 

executed function is a 'Status Update' type function. associated with each of the current active process steps. An 

Preferably, function names indicate the type of function. In active process step is a step that is currently pending and 

this example, certain internal functions having the type ready to processed. Specifically, in this example, active 

'Status Update', 'Activate Step' and 'Change SubLine' are process steps have been initialized via the INITIALIZE 

tested in steps 604, 610 and 614, respectively. The meaning 50 method, which is called from the SYNC method 512, and is 

of each of these function types are described below. subsequently described below. The effect of active process 

It should be noted that the three types of internal functions steps is that they appear in one or more workflow queues 

described above, are all executed by the SYNC method 512 312, which indicates to users that the process step is ready 

(described below). The SYNC method 512 calls the to be processed. 

NOTICE method 508 after executing the related internal 55 As stated, the NOTICE method 508 finds process steps 
function (See SYNC method 512, steps 710, 728 and 740). that need to be evaluated by searching each function list 
Accordingly, the workflow manager of the present invention associated with each active process step. Function fists are 
NOTICES functions that are executed by itself. preferably generated by the present invention before run- 
Referring back now to step 604, the NOTICE method 508 time to more efficiently find process steps that may be 
determines if the function is of the type 'Status Update'. This 60 affected by functions during run-time. Function lists are a 
indicates that the status 416 of the process step '<process>' list of functions associated with a process step that can 
was just updated. In this case, the parent step of <process> potentially affect the status of the process step. These 
(referred to as ThatProcess) needs to be re-evaluated. function lists are new lists that are derived from the asso- 
Accordingly, as indicated by step 608, the NOTICE method ciations between the process steps 310, tests 308, rule 
508 determines if such a parent process step exists. If a 65 elements 306, database elements 304 and functions 302. The 
parent process step does not exist, control passes to step 632, function lists directly link process steps to functions that 
where the NOTICE method 508 ends. may affect them. 
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Next in step 630, the process steps found in step 622 are 
added to the processList, if they are not already present. The 
NOTICE method 508 then ends as indicated by step 632. 

An example of a method that can be used to implement 
the SYNC method 512 will now be described with reference 
to FIG. 7. The SYNC method begins with step 702, where 
control immediately passes to step 704. In step 704, the 
method determines if the ProcessList is empty, and if so, the 
method ends, as indicated by step 742. If the processList is 
not empty, control passes to step 706. In step 706, the first 
process step is retrieved from the processList. 

Next, in step 710, the SYNC method 512 determines 
whether the SubLine has changed, and if so, calls the 
NOTICE method 508, to force the workflow management 
system to notice the change to the SubLine. Control then 
passes to step 712. In step 712, the method determines if the 
process step is of the type 'automatic' 414. If it is, control 
passes to step 714, where the automatic process step is 
automatically executed by the workflow management sys- 
tem. After the function associated with the automatic step 
has been executed in step 714, the SYNC function calls the 
NOTICE method 508, so that the appropriate process steps 
are evaluated in response to the automatically executed 
function. Control then passes to step 716. 

If step 712 determines that the process step is not an 
automatic step, control passes to step 726. In step 726, the 
SYNC method 512 calculates the status 416 of the process 
step. This is preferably accomplished by examining the tests 
412 associated with the process step. For a normal step 414, 
the SYNC method will examine the skip tests 422, to 
determine if the step should be skipped. If the process step 
is not skipped then the completion tests 422 are examined. 
If all the completion tests pass, this indicates that the process 
step is now complete and the status 416 changes from 
incomplete to complete. If any of the completion tests are 
FALSE, the process step is not complete and the status 416 
remains unchanged and incomplete. 

If the process step is of the type exception 414, the 
completion and skip tests 422 are the same. Accordingly, the 
rules 412 associated with an exception step are both the skip 
and completion rules. Thus, for exception steps, if at least 
one of the rules fail, an exception is indicated and the status 
416 for the step is incomplete. This will prompt attention 
from a user, that action is required to complete the process 
step. Once the user performs the required action, these tests 
will be executed again. If at that time, all of the tests pass, 
the step will be tagged with a complete status. If all of the 
tests for an exception step pass the first time through, there 
is no exception and the rule is skipped. The status 416 for a 
skipped exception rule is non-applicable (N/A). 

After the status of the process step is calculated in step 
726, control passes to step 730. In step 730, the SYNC 
method 512 determines if the new status is different from the 
previous status (i.e. if the status has changed). If so, the 
process step is stamped with the new status 416 as indicated 
by step 732. Next, in step 734, the SYNC method determines 
if the new status is a complete status 416. If so, control 
passes to step 738. 

In step 738 another method referred to herein as INI- 
TIALIZE is called. The INITIALIZE method 738 essen- 
tially finds the next process step in the workflow and 
activates that step. The INITIALIZE method 738 is 
described in detail below. After calling the INITIALIZE 
method, control passes to step 740, where the NOTICE 
method 508 is called in response to the status update of the 
process step. 
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If the status has not changed according to step 730, 
control passes to step 716. Control also passes to step 716 
after step 728 as described above. In step 716, the SYNC 
method 512 determines if the process step is 'collateral 

5 specific' 420. If the process step is 'collateral specific' 420 
the method loops back to step 712 and repeats the above 
method steps for each additional item of collateral listed in 
the credit application. Collateral specific 420 process steps 
are steps that need to be performed one time for each item 

10 of collateral listed in the credit application. Accordingly, if 
the current step is collateral specific, control passes back to 
step 712, and the method steps are repeated for each item of 
collateral. If the process step is not collateral specific, or if 
the above method steps have been repeated for all associated 

15 items of collateral, control passes to step 718. 

In step 718, the SYNC method 512 determines if there are 
additional process steps to processed in the processList. If 
so, control passes back to step 706, and the method repeats 
the above described method steps for the next process step. 

20 If all process steps in the processList have been processed by 
the SYNC method 512, control passes to step 720. In step 
720, the method determines if there are any process steps 
remaining in the workflow that have a status 416 of 'incom- 
plete/ If so, control passes to step 722, where the SYNC 

25 method 512 finds the next set of steps having an incomplete 
status which are to become the next active steps in the 
workflow. This is accomplished with the use of the 'follow 
step* indicator 420, as described above, for each of the 
completed steps. If there are no steps with a status of 

30 incomplete, the application is complete as indicated in step 
724. The SYNC method 512 ends with step 742. 

FIG. 8 is an example method that can be used as the 
INITIALIZE method according to a preferred embodiment 
of the present invention. The INITIALIZE method 738 

35 essentially builds the workflow by activating process steps 
that depend from a process step whose status just changed to 
complete ('the completed step*), according to step 734 in the 
SYNC method 512. 

4Q The INITIALIZE method 738 begins with step 802, 
where control immediately passes to step 804. In step 804 
the method finds the next process step that follows the 
completed step. If there is such a step as determined in step 
806, control passes to step 808. In step 808, the next process 

45 step is initialized by calling another method referred to 
herein as INITTALIZESTEP. A method that can be used for 
the INITIALIZESTEP 808 is described below. After INI- 
TTALIZESTEP is called control passes back to step 804, 
where the method is completed until there are no remaining 

50 steps that follow the current process step. Control then 
passes to step 810, where the INITIALIZE method 738 ends. 

FIG. 9 is an example method that can be used as the 
INITIALIZESTEP method according to a preferred embodi- 
ment of the present invention. In INITIALIZESTEP, one or 

55 more process steps are activated and become part of the 
processList. The INITIALIZESTEP method 808 begins with 
step 902, where control immediately passes to step 904. In 
step 904 the method activates the process step passed into 
the method, referred to as 'ThisStep'. It should be recalled 

6Q that 'ThisStep* was determined to be the step that follows the 
completed step from the INITIALIZE method 738, as deter- 
mined in step 808 of that method. 

As stated, a step is active when it becomes part of the 
current workflow and is ready to be processed. Active steps 

65 are steps whose predecessor steps have been completed. 
Next in step 906, the INITIALIZESTEP method determines 
the SubLine of the process step. This is done in order to 
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determine if the process step has as status 416 of N/A and which allow software and data to be transferred from the 
should therefore be skipped. This is accomplished by evalu- removable storage unit 1022 to computer system 1001. 
a ting the skip rules 422 associated with the process step. If Computer system 1001 can also include a communica- 
the process step is to be skipped, there is no need to activate tions interface 1024. Communications interface 1024 allows 
the child steps associated of the process step. Accordingly, 5 software and data to be transferred between computer sys- 
as step 910 indicates, if the process step has a status of N/A, tem 1001 and external devices. Examples of communica- 
control passes to step 918, where the NOTICE method 508 ti° ns interface 1024 can include a modem, a network inter- 
is called so that the workflow management system knows to face ( such ^ an Ethernet card), a communications port, a 
evaluate the status of the step. The method then ends as PCMCIA slot and card, etc. Software and data transferred 
indicated by step 920. in v * a communications interface 1024 are in the form of signals 
T r 4 j 4 . 4 . j-i/- r l it j * # which can be electronic, electromagnetic, optical or other 
If the process step does not have a status 416 of 'N/A', $j fc Wc of bei receivcd by % om ^i ca ,i ons ^ 

C ™™ paS f Ylr 6 P . ln Step 0,6 1N111AU *- face 1024. These signals 1026 are provided to communica- 
ESTEP method 808 determines whether the process step is tions interface via a channel 1028. This channel 1028 carries 
'collateral specific' 420. If it is, control passes to step 924, s j gna]s 10 26 and can be implemented using wire or cable 
where a separate copy of the process step is activated for 15 fiber optics, a phone line, a cellular phone link, an RF link 
each collateral item in the credit application. Control then and other communications channels, 
passes to step 925 where the NOTICE method 508 is called ln mis docume nt, the terms "computer program medium" 
so that the steps just activated are noticed by the workflow and "computer usable medium" are used to generally refer 
management system. Control then passes to step 914. to media such as rem0 vable storage device 1012, a hard disk 
If step 912 determines that the process step is not collat- 20 installed in hard disk drive 1010, and signals 1026. These 
eral specific, control passes to step 914. In step 914, the computer program products are means for providing soft- 
method searches for a child step whose parent is 'ThisStep' ware to computer system 1001. 

and does not follow another step. Tliat is, the method looks Computer programs (also called computer control logic) 

for a child step that does not depend on another step being are stored in main memory and/or secondary memory 1008. 

completed. If such a step is found, this process INITIAL- 25 Computer programs can also be received via communica- 

IZESTEP is recursively called for the child step. If there is tions interface 1024. Such computer programs, when 

no such child step, control passes to step 918 where the child executed, enable the computer system 1001 to perform the 

step is noticed by the workflow management system and features of the present invention as discussed herein. In 

method ends, as indicated by step 920. particular, the computer programs, when executed, enable 

The present invention may be implemented using the processor 1004 to perform the features of the present 

hardware, software or a combination thereof and may be invention. Accordingly, such computer programs represent 

implemented in a computer system or other processing controllers of the computer system 1001. 

system. In fact, in one embodiment, the invention is directed In an embodiment where the invention is implemented 

toward a computer system capable of carrying out the 35 using software, the software may be stored in a computer 

functionality described herein. An example computer system program product and loaded into computer system 1001 

1001 is shown in FIG. 10. The computer system 1001 using removable storage drive 1012, hard drive 1010 or 

includes one or more processors, such as processor 1004. communications interface 1024. The control logic 

The processor 1004 is connected to a communication bus (software), when executed by the processor 1004, causes the 

1002. Various software embodiments are described in terms 4Q processor 1004 to perform the functions of the invention as 

of this example computer system. After reading this described herein. 

description, it will become apparent to a person skilled in the m another embodiment, the invention is implemented 
relevant art how to implement the invention using other primarily in hardware using, for example, hardware corn- 
computer systems and/or computer architectures. ponents such as application specific integrated circuits 
Computer system 1002 also includes a main memory 45 (ASICs). Implementation of the hardware state machine so 
1006, preferably random access memory (RAM), and can as to perform the functions described herein will be apparent 
also include a secondary memory 1008. The secondary to persons skilled in the relevant art(s). 
memory 1008 can include, for example, a hard disk drive In yet another embodiment, the invention is implemented 
1010 and/or a removable storage drive 1012, representing a using a combination of both hardware and software, 
floppy disk drive, a magnetic tape drive, an optical disk 50 White various embodiments of the present invention have 
drive, etc. The removable storage drive 1012 reads from been described above, it should be understood that they have 
and/or writes to a removable storage unit 1014 in a well been presented by way of example only, and not limitation, 
known manner. Removable storage UDit 1014, represents a Thus, the breadth and scope of the present invention should 
floppy disk, magnetic tape, optical disk, etc. which is read by not be limited by any of the above-described exemplary 
and written to by removable storage drive 1012. As will be 55 embodiments, but should be defined only in accordance with 
appreciated, the removable storage unit 1014 includes a the following claims and their equivalents, 
computer usable storage medium having stored therein What is claimed is: 

computer software and/or data. i. A method for dynamically managing workflow for an 

In alternative embodiments, secondary memory 1008 may automated credit application system in response to functions 

include other similar means for allowing computer programs 60 executed by a user or by the automated credit application 

or other instructions to be loaded into computer system system, comprising the steps of: 

1001. Such means can include, for example, a removable configuring a workflow for a credit application, compris- 

storage unit 1022 and an interface 1020. Examples of such ing the steps of: 

can include a program cartridge and cartridge interface (such defining a plurality of workflow process steps, each 

as that found in video game devices), a removable memory 65 said workflow process steps having an associated 

chip (such as an EPROM, or PROM) and associated socket, status, wherein said status can be complete or incom- 

and other removable storage units 1022 and interfaces 1020 plete; 



06/07/2004, EAST Version: 1.4.1 



US 6,505,176 B2 



17 



18 



associating one or more tests with each of said work- 
flow process steps; 

relating one or more database elements with each of 
said tests; and 

linking one or more functions with each of said data- 5 
base elements; and 
processing a workflow for the credit application, com- 
prising the steps of: 

identifying an executed function, wherein said 
executed function can be executed by the user or by 10 
the automated credit application system; 

finding a set of potentially affected workflow process 
steps comprising all workflow process steps associ- 
ated with said executed function; 

calculating the status of each workflow process step in 15 
said set of potentially affected workflow process 
steps; 

dynamically determining, in response to said identify- 
ing step, said finding step and said calculating step, 
a next step for each said workflow process step 20 

in said set of potentially affected workflow process 
steps, in which said status changes from incomplete 
to complete according to said calculating step; and 

associating a level of security with each of said func- 
tions and the user and wherein a particular function 25 
can only be executed by the user if the user is 
associated with the same or higher level of security 
as said particular function. 

2. The method of claim 1, wherein said configuring step 
further comprises the step of creating a function list asso- 30 
ciated with each said workflow process steps, each said 
function list comprising a list of functions associated with 
the corresponding workflow process step, wherein said 
function list is created by examining relationships between 
said workflow process steps, said tests, said database ele- 35 
ments and said functions, according to relationships estab- 
lished by said associating, relating and linking steps. 

3. The method of claim 2, wherein said processing step 
further comprises the step of: 

creating a process list comprising a list of workflow 40 
process steps that are currently active; and 

said finding step is accomplished by evaluating each said 
function list associated with each said workflow pro- 
cessing step that is currently active according to said 
process list. 

4. The method of claim 2, wherein said finding step is 
accomplished by evaluating each said function list associ- 
ated with each said workflow processing step. 

5. The method of claim 1, wherein said finding step is 50 
accomplished by examining relationships between said 
workflow process steps, said tests, said database elements 
and said functions, according to relationships established by 
said associating, relating and linking steps. 

6. The method of claim 1, wherein said processing step 55 
further comprises the step of creating a process list com- 
prising a list of workflow process steps that are currently 
active. 

7. The method of claim 1, wherein said processing step 
further comprises the step of: 6Q 

creating a process list comprising a list of workflow 
process steps that are currently active; and 

said finding step is accomplished by examining relation- 
ships between said currently active workflow process 
steps, said tests, said database elements and said 65 
functions, according to relationships established by 
said associating, relating and linking steps. 
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8. The method of claim 1, wherein said calculating step 
comprises the step of evaluating said at least one said tests 
associated with each of said workflow process steps in said 
set of potentially affected workflow process steps. 

9. The method of claim 1, wherein said associating step 
comprises the step of associating one or more rule elements 
to one or more of said database elements, wherein each of 
said rule elements is associated with one or more of said 
tests. 

10. A system to dynamically manage workflow for an 
automated credit application system in response to functions 
executed by a user or by the automated credit application 
system, comprising: 

a function module comprising a plurality of functions, 
each of said functions can be executed by the user or by 
the automated credit application system; 

a test module comprising a plurality of tests, each of said 
tests associated with at least one of said functions; 

a data module comprising a plurality of workflow process 
steps for an credit application, each of said workflow 
process steps associated with at least one of said tests; 

a notice module responsive to an executed function in said 
function module, wherein said notice module is used to 
identify which said workflow process steps for the 
credit application are associated with said executed 
function; and 

a security feature coupled with said function module, 
wherein each of said functions and the user are asso- 
ciated with a level of security and wherein a particular 
function can only be executed by the user if the user is 
associated with the same or higher level of security as 
said particular function, 

11. The system of claim 10, further comprising: 

a database element module, comprising a plurality of 
database elements, each of said database elements 
associated with at least one of said functions; and 

a rules module comprising a plurality of rule elements, 
each of said rule elements associated with one or more 
of said database elements, and each of said rule ele- 
ments associated with one or more of said tests. 

12. The system of claim 10, wherein said test module 
comprises completion tests, skip tests and exception tests. 

13. The system of claim 10, wherein said workflow 
process steps include an associated status, wherein said 
associated status can be incomplete, non-applicable, com- 
plete or waived. 

14. The system of claim 10, wherein said plurality of 
workflow process steps are organized in specified order. 

15. The system of claim 10, wherein said plurality of 
workflow process steps are organized in a hierarchy, wherein 
each said workflow process step can have a parent and a 
child. 

16. The system of claim 10, further comprising: 

a calculate status module for calculating the status of each 
of said workflow process steps associated with said 
executed function; and 

a dynamic module, responsive to said calculate status 
module, for dynamically determining the next process 
step of said workflow process steps to be executed. 

17. A computer program product comprising a computer 
useable medium having computer program logic stored 
therein, said computer program logic for dynamically man- 
aging workflow for an automated credit application system 
in response to functions executed by a user or by the 
automated credit application system, wherein said computer 
program logic comprises: 
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configuring means for enabling the computer to configure 
a workflow for a credit application, comprising: 
defining means for enabling the computer to accept 
from a user a definition for a plurality of workflow 
process steps, each said workflow process steps 5 
having an associated status, wherein said status can 
be complete or incomplete; 
associating means for enabling the computer to asso- 
ciate one or more tests with each of said workflow 
process steps; 10 
relating means for enabling the computer to relate one 
or more database elements with each of said tests; 
and 

linking means for enabling the computer to link one or 
more functions with each of said database elements; 15 
and 

processing means for enabling the computer to process 
a workflow for the credit application, comprising: 
identifying means for enabling the computer to iden- 
tify an executed function, wherein said executed 20 
function can be executed by the user or by the 
automated credit application system; 
finding means for enabling the computer to find a set 
of potentially affected workflow process steps 
comprising all workflow process steps associated 25 
with said executed function; 
calculating means for enabling the computer to cal- 
culate the status of each workflow process step in 
said set of potentially affected workflow process 
steps; 30- 
dynamic determining means, responsive to said iden- 
tifying means, said finding means and said calcu- 
lating means, for enabling the computer to deter- 
mine a next step for each said workflow process 
step in said set of potentially affected workflow 35 
process steps, in which said status changes from 
incomplete to complete according to said calcu- 
lating means; and 
security means for associating a level of security 
with each of said functions and the user and 40 
wherein a particular function can only be executed 
by the user if the user is associated with the same 
or higher level of security as said particular func- 
tion. 

18. The computer program product of claim 17, wherein 45 
said configuring means further comprises means for 
enabling the computer to create a function list associated 
with each said workflow process steps, each said function 
list comprising a list of functions associated with the cor- 
responding workflow process step, wherein said function list 50 
is created by examining relationships between said work- 
flow process steps, said tests, said database elements and 
said functions, according to relationships established by said 
associating, relating and linking means. 

19. The computer program product of claim 18, wherein 55 
said processing means further comprises: 

means for enabling the computer to create a process list 
comprising a list of workflow process steps that are 
currently active; and 



said finding means is accomplished by evaluating each 
said function list associated with each said workflow 
processing step that is currently active according to said 
process list. 

20. The computer program product of claim 18, wherein 
said finding means is accomplished by evaluating each said 
function list associated with each said workflow processing 
step. 

21. The computer program product of claim 17, wherein 
said finding means is accomplished by examining relation- 
ships between said workflow process steps, said tests, said 
database elements and said functions, according to relation- 
ships established by said associating, relating and linking 
means. 

22. The computer program product of claim 17, wherein 
said processing means further comprises means for enabling 
the computer to create a process list comprising a list of 
workflow process steps that are currently active. 

23. The computer program product of claim 17, wherein 
said processing means further comprises: 

means for enabling the computer to create a process list 
comprising a list of workflow process steps that are 
currently active; and 

said finding means is accomplished by examining rela- 
tionships between said currently active workflow pro- 
cess steps, said tests, said database elements and said 
functions, according to relationships established by 
said associating, relating and linking means. 

24. The computer program product of claim 17, wherein 
said calculating means comprises means for enabling the 
computer to evaluate said at least one of said tests associated 
with each of said workflow process steps in said set of 
potentially affected workflow process steps. 

25. A method for dynamically managing one or more 
workflow process steps for an automated credit application 
system in response to functions executed by a user or by the 
automated credit application system, comprising the steps 
of: 

linking at least one rule test with each of the workflow 

process steps for a credit application; 
linking at least one rule element with each of said rule 

tests; 

linking each of said rule tests with at least one database 
element; 

linking each of said database elements to at least one of 
the functions; 

executing, by the user or by the automated credit appli- 
cation system, one of the functions, wherein the 
executed function alters said database elements, 

determining which of the workflow process steps for the 
credit application is next activated; and 

associating a level of security with each of said functions 
and the user and wherein a particular function can only 
be executed by the user if the user is associated with the 
same or higher level of security as said particular 
function. 
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